On 05/21/10 08:31 AM, James Carlson wrote:
Darren J Moffat wrote:
On 21/05/2010 12:20, James Carlson wrote:
On 05/20/10 22:51, Don Cragun wrote:
Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a
"Conforming POSIX Application Using Extensions" is free to use
LOGNAME_MAX as defined in<limits.h> as long as it documents that it
uses this macro (and __EXTENSIONS__ as defined on the standards(5)
man page). You may wish that applications wouldn't do that, but
according to the standards, using documented features of an
implementation is not a bug; it just makes the program source less
portable.
That only counts when in such an environment, though. A reasonable
solution (borrowing from Bill's suggestion) would be to have LOGNAME_MAX
defined as 9 when in a conforming environment, and intentionally
undefined elsewhere.
No I don't think that is reasonable, because it will only cause to
create applications that can only deal with shorter usernames which will
be different to the rest of the system. For the #define it will only
come into play if the application is recompiled on a release with this
change. Ultimately this just causes problems for users and admins.
It preserves the existing branding, allows "normal" applications to be
improved, and permits those who feel they need strict conformance to get
it. You can't have everything.
Assuming there is a standards-conformance issue that requires the
smaller value in some circumstances [1], I don't see the downside in
providing the old #define for compilations that specifically request the
conforming environment.
It still lets us take advantage of longer usernames for everything in
Solaris and most real-world programs without making the
conformance/branding situation any more difficult than it already is.
Scott
[1] I haven't studied that issue carefully, but I'm willing to accept
that such a situation exists.
--
Scott Rotondo
Senior Principal Engineer, Solaris Core OS Engineering
President, Trusted Computing Group
Phone: +1 650 786 6309 (Internal x86309)
_______________________________________________
opensolaris-arc mailing list
[email protected]