On 21/05/2010 16:19, James Carlson wrote:
The second is the standards group branding issue. The value 9 is baked into the UNIX98 and UNIX03 reference materials, so changing it (at least inside those conforming environments) means either re-doing the branding or ceasing to be "UNIX" in that sense. Obviously not an architectural issue, but something non-trivial that should be noted.
My understanding is that this is the distinction between _POSIX_LOGIN_NAME_MAX which this case explicitly stated stays a 9, and LOGIN_NAME_MAX which is only required to be a minimum of _POSIX_LOGIN_NAME_MAX.
The #define I'm changing in <limits.h> is neither of those it is LOGNAME_MAX. The #define in <limits.h> for _POSIX_LOGIN_NAME_MAX stays at 9.
I could be convinced to just take LOGNAME_MAX out of scope and make it Consolidation Private - or maybe to remove it completely. This I believe is Bill's preference.
I was hoping to convince you that, although there's nothing wrong with the proposal, and that it's technically simple to accomplish, the nature of it places it outside the bounds of a traditional fast-track, and that allowing "mission creep" on fast-tracks is a bad thing overall for OpenSolaris.
What you aren't convincing me of is what value an ARC opinion will have in this particular case.
I see no value in an ARC opinion here since there has been no suggested Advice to any other party.
-- Darren J Moffat _______________________________________________ opensolaris-arc mailing list [email protected]
