On 05/20/10 19:57, James Carlson wrote:
Of course, I welcome the change, and I'd be quite surprised if Informix
up 'n fell over on it. It's about danged time. I'm sure Mr. Sommerfe
and the Legions of the Truncated Surnames will agree. ;-}
Indeed.
Where possible, I've been running with a 10-character username in
/etc/passwd since I started at sun in 2000 ; I've also verified that
this works in NIS. I've run into surprisingly few bugs. More than a
few deltas in the teamware/SCCS sources used for solaris 10 and earlier
were created by the user "sommerfeld".
Nothing in solaris 8 or later (and I haven't verified earlier releases)
prevents an application from seeing a longer-than-LOGNAME_MAX string
from pwd.pw_name.
What's more, administrators who use "useradd" to add a user with a long
name will see a warning message, but the user will be added to
/etc/passwd file anyway.
So nothing compiled into the code enforces an 8-character maximum today
if a system administrator chooses to use longer usernames; all that
really remains of the limit is the attractive nuisance of LOGNAME_MAX.
One alternative that I haven't fully explored is to (conditionally or
unconditionally) delete LOGNAME_MAX from limits.h, forcing applications
to rely on the dynamic size returned by sysconf(). We have long
recognized an exception to the backwards compatibility requirements when
an interface contains an inherent risk of data corruption, and that
seems to be evident here; given that an alternative interface exists
(sysconf(_SC_LOGIN_NAME_MAX)), and also given the prevalence of other
systems which don't bother to define LOGNAME_MAX, this may well be a
safer path.
- Bill
_______________________________________________
opensolaris-arc mailing list
[email protected]