>> Evangelical points of view aside, though, it does seem to me that if
>> you're going to break binary compatability anyway, you should do so
>> in an extensible way: redefine the file format so that it includes
>> all these lengths in the file, so that when someone wants usernames
>> longer than 16, or whatever, we don't have this situation happening
>> again.

> I presume you're implying that software should check what sizes the
> file is using and DTRT.

Well, yes; there isn't much point in putting the sizes in the file
unless software uses them (or at least is expected to use them).

> That would be nice, but what do you do about the in-core format?  And
> how do you inform the applications what the sizes are?

Since at present there is no library interface around utmp (at least
not as far as I can determine from -current manpages as of "a little
while" ago, nor from reading the source to who), the entire file format
is exposed to the application.  Therefore, just as with the current
format, the in-core format is whatever the application chooses.  (The
current file format happens to be such that a block transfer of some
number of bytes (currently sizeof(struct utmp)) from disk to memory
results in a memory layout matching a struct from an include file; this
may or may not remain so, depending on the redesign.)

> There's a lot of code in the world, including much of our own, that
> uses sizeof(ut_name) and/or UT_NAMESIZE, etc.  What do you do about
> them?

Perforce, either break it or pick some large size - maybe 255 if you
use one-byte on-disk sizes.  But...

> Pick some large in-core size, and always truncate in the library?
> Anything else is going to break source compatibility.

...since there currently is no "the library", changing the file format
at all is perforce going to break source code compatability.  (Unless,
perhaps, you boost the sizes to 255 and watch utmp and wtmp explode
on-disk.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D