On May 21, 2010, at 16:30:01 +0100, [email protected] wrote: > 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.
Yes, _POSIX_LOGIN_NAME_MAX must be defined and must have the value 9 on all conforming implementations. Yes, LOGIN_NAME_MAX must have a value >= _POSIX_LOGIN_NAME_MAX or be "unlimited" (signified by value -1). However, the value of LOGIN_NAME_MAX must be documented in the conformance statement questionnaire which is part of the UNIX branding package. The Oracle CSQ for Solaris X86 Platform Edition on releases 10 and on and for Solaris SPARC Platform Edition on releases 10 and on in the Mandatory Products Standards section on Internationalised System Calls and Libraries Extended V3 as documented in http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7 specifies that the minimum value of LOGIN_NAME_MAX is 9 and the maximum value of LOGIN_NAME_MAX is 9. So, making the changes proposed in this case require one of the following: 1. apply for a new brand for whatever Solaris release contains this change, or 2. stop using the UNIX trademark. > > 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. Removing a committed interface in a minor release is not appropriate. > >> 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. As noted above, this is not an ARC issue, but it is a business issue. In my not so humble opinion, this requires some party or parties outside of the ARC within Oracle to be notified of the impact of this change. Therefore, I believe an opintion needs to be written. - Don > > -- > Darren J Moffat _______________________________________________ opensolaris-arc mailing list [email protected]
