On May 20, 2010, at 2:24 PM, Garrett D'Amore wrote:
> On 05/20/10 02:06 PM, I. Szczesniak wrote:
>> On Thu, May 20, 2010 at 9:18 PM, Don Cragun<[email protected]> wrote:
>>
>>> The reason that LOGNAME_MAX was stuck at 8 in<limits.h> for so long
>>> is that the System V ABIs and the SCDs require that value.
>>>
>>> Solaris 10 has been breaking ABI requirements around the edges for a
>>> few years. Since this is case is departing from more ABI
>>> requirements, should it have a major release binding? Or, should an
>>> opinion be written for this case acknowledging that the ARC knows
>>> that this case violates the ABIs and that the decision to do so is
>>> intentional (without setting precedent to otherwise ignore the ABI)?
>>>
>>> Once upon a time, there was a gang of four working on a
>>> definition of what would be the limits of the changes going into
>>> "Solaris next", whether it would be classified as a major or minor
>>> release, and what would constitute the basis for determining whether
>>> or not an implementation of OpenSolaris would be able to use the
>>> Solaris trademark. Was a report ever produced by the gang? (I know
>>> that at least half of the gang no longer works for Sun/Oracle.) Is
>>> there any current plan to define any type of new Solaris ABI?
>>>
>> I agree with Don that at *least* an opinion must be written for such a
>> change. You will at least break major software like Informix with this
>> change.
>>
>
> Huh?
>
> I'm not disagreeing that an opinion is warranted, but it seems to me that
> we're lifting a restriction; whether software is busted or not as a
> consequence depends on whether
>
> a) the software is coded properly to inquire about limits using the proper
> APIs.
According to the Solaris 10 limits.h(3HEAD) man page, LOGNAME_MAX is an
invariant value defined in <limits.h>. It is described there as:
"The maximum number of bytes supported in a user's login name."
So it is perfectly legitimate for a Solaris 10 application to define
an array as char logname[LOGNAME_MAX + 1] and copy an entry from a
struct passwd using
strncpy(logname, pwd.pw_name, LOGNAME_MAX);
logname[LOGNAME_MAX] = '\0';
and know that it has copied the entire user's login name out of the
struct passwd. Programs aren't usually supposed to have to be rebuilt
for a Solaris minor release to continue working. That is why I
originally questioned whether this change should have a major release
binding.
Note also that the value of LOGIN_NAME_MAX is specified to be 9 in
Oracle's (and Fujitsu's) UNIX '98 and UNIX '03 branding CSQs. If
you're going to change this value, Oracle will need to file for a new
UNIX brand and pay the associated branding fees to TOG. If Fujitsu
is still partnering with Oracle to provide a Solaris OS for Fujitsu
hardware, you will also need to notify Fujitsu that they'll need to
rebrand as well. (There are ways around this if sysconf() returns
different values for different programming environments, but if you
do that you will break strictly conforming applications if you
allow longer login names to be visible to applications built using
the current SUSv2 and SUSv3 programming environments.
> b) the site has chosen to exercise longer usernames
>
> Both must be true for rationale cases of breakage. Of course there is an
> irrationale case as well:
>
> c) software inquiries the limit, but is defective and unable to handle a
> value other than the legacy one (for example by using a fixed size array, but
> bzeroing the array using the results of the inquiry to determine the length!)
> Obviously such software would be so horrendously buggy that we can't
> possibly be held accountable for this kind of breakage.
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.
- Don
> - Garrett
>
>> Irek
>>
>
_______________________________________________
opensolaris-arc mailing list
[email protected]
