Usernames > 16 characters
Garance A Drosihn
drosih at rpi.edu
Mon Aug 18 16:26:25 PDT 2003
At 3:17 PM -0700 8/18/03, Matthew Dillon wrote:
:Is that 32 bytes which includes the terminating null character
:(where there is a terminating null character), or 32 characters
:without counting the terminating null? I have no preference,
:it's just a detail which is nice to state explicitly, in case
:different people make different assumptions.
:
:(same question for 16 and 48 byte limits...)
Well, that goes to the historical nature of utmp/wtmp/lastlog.
These structural files traditionally allowed names to be as
long as the actual buffer (i.e. not have a terminating \0 byte),
and many programs which write into them are likely to do so.
My preference is to always require a terminating \0 (making
the limit one less then the macro says), but I recognize the
reality of the situation which is that all code that accesses
these structures had better be able to handle a non-terminated
full-length name in the buffer.
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
Senior Systems Programmer or gad at xxxxxxxxxxx
Rensselaer Polytechnic Institute or drosih at xxxxxxx
More information about the Kernel
mailing list