Subject: Re: endianness agnostic getpwent()
To: None <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 11/11/2000 23:08:31
Jaromír Dolecek <firstname.lastname@example.org> wrote:
> Hmm, dbopen(3) accepts openinfo
> argument, which can be used to pass access-method specific data.
> We can change it so that if openinfo is specified and file already exists,
> lorder (see hash(3)) of passed structure is set to byte order of the db.
> Then, we would not need any special entry in the database file to find
> out its endianness.
> Other possible hack is to add flag R_ENDIANNESS and cause DB->get()
> with flag == R_ENDIANNESS to return endianness indication.
I've thought about this in the past (specifically with lorder), but
any such changes that we would make (and use) to the db library will
render us incompatible with all other implementations of that library.
I think that this would end up creating more problems than we are trying
to solve. And with the getpwent() case specifically, we _still_ have
backwards compatibility to worry about.
I think the best solution is to add another set of keys and leave the
existing host byte orders keys in to support old static banaries. I
don't know whether ASCII keys or network byte order keys are better.
Then in <pwd.h> we have
#define _PW_KEYBYNAME 'A' /* stored by name */
#define _PW_KEYBYNUM 'B' /* stored by entry in the "file" */
#define _PW_KEYBYUID 'C' /* stored by uid */
#define _PW_OKEYBYNAME '1' /* compat: by name */
#define _PW_OKEYBYNUM '2' /* compat: by entry number */
#define _PW_OKEYBYUID '3' /* compat: by uid */
with the _PW_KEY* keys in which ever format we decide is best and
the _PW_O* entries for backwards compatibility in host byte order.
pwd_mkdb(8) is then updated to add both key types for each entry.
Arguably ASCII keys might make life easier from a maintenence
Simon Burge <email@example.com>
NetBSD Sales, Support and Service: http://www.wasabisystems.com/