Usernames > 16 characters
dillon at apollo.backplane.com
Mon Aug 18 19:00:24 PDT 2003
: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 at 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 at 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.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel