Re: Usernames > 16 characters

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hmm.  Not sure that answered my question.
:
:Will dragonfly allow for userids which are 32 printable characters,
:or will it be 31 characters?  For code which *does* need the
:trailing null when working with userids, will that code need to
:have 32 or 33 byte character arrays?
:
:As to utmp/wtmp, I suppose you could always define the field to
:be (say) 31 characters, and then follow it with an unused byte
:that would always be zero.  </pointless-rambling>
:
:What would be best to do is finally implement the utmpx-related
:routines from POSIX/SingleUnixSpec.  I still have a message that
:Nathan Hawkins <utsl@xxxxxxxx> wrote to freebsd-standards in
:March 2002, where he had written a good initial start at those
:routines.  We should encourage programs to use that API to play
:with the utmp entries, instead of going directly to the files.
:(by "we" I really mean "all the BSD's".  I had intended to try
:to add those to freebsd, but keep forgetting about it).
:
:-- 
:Garance Alistair Drosehn            =   gad@xxxxxxxxxxxxxxxxxxxx

    Well, any direct access to the utmp file has to allow for a full-length
    (unterminated) string.  That's just the way the structure works.

    But, if we implemented an API through a port service, meaning that
    direct utmp file access and file modification by the program would be
    completely disallowed, then the buffer termination issues become
    irrelevant because only the port service would be able to mess with
    the actual file.

    utmpx is not any better then utmp.  It is still using direct structures
    and, worse, it is using embedded char arrys in those structures, and it
    uses a non-portable time format.  In a word: they had a chance to fix
    all the problems and didn't fix any of the problems.   Something like
    the getpw*() function set is a far better API.  Those structures
    contain string pointers rather then embedded char arrays.

    So whatever succeeds utmp it isn't going to be utmpx.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>