This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: strtoul(-1) discussion
- From: Fabrice Bauzac <libnoon at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-help at sourceware dot org, Alexandre Oliva <aoliva at redhat dot com>
- Date: Sun, 19 May 2013 20:23:49 +0200
- Subject: Re: strtoul(-1) discussion
- References: <CAB6Q1a-m=W4cA3WCeuB1FzFWHbistLrN3wR1hfo4mfPB9j9qJw at mail dot gmail dot com> <51619DB2 dot 10406 at redhat dot com> <CAB6Q1a_QvSAqRODp7481=q7RLjmzR1=04UW3r7D1WQmFSeYsdQ at mail dot gmail dot com>
Hello,
According to some discussion on the austin-group mailing list, it
hopefully seems that the glibc's implementation is correct wrt POSIX.
Therefore the patch I have sent earlier should not be included.
However, it might be a good idea to document that strtoul is unable to
distinguish "-1" from "4294967295", and recommend to use the signed
variant strtol or to manually check the presence of the minus sign.
I'll follow the austin group discussion around it, and if it is
confirmed I'll try to post a patch.
Thanks!
Best regards
Fabrice
2013/4/14 Fabrice Bauzac <libnoon@gmail.com>:
> Hello,
>
> Here is, attached, a proposal for updating the documentation.
>
> Thanks a lot!
>
> Best regards
> Fabrice
>
> 2013/4/7 Carlos O'Donell <carlos@redhat.com>:
>> On 04/07/2013 09:20 AM, Fabrice Bauzac wrote:
>>> Hello,
>>>
>>> I might have found a defect of glibc's strtoul with regards to POSIX.
>>> I have done that long ago, but hesitated to post it until now.
>>
>> Thanks for posting your analysis!
>>
>>> The problem is that [1] says:
>>>
>>> "If the correct value is outside the range of representable values,
>>> {ULONG_MAX} or {ULLONG_MAX} shall be returned and errno set to
>>> [ERANGE]."
>>
>> OK.
>>
>>> If my interpretation is correct, this means that strtoul should not
>>> fail when given "-0" but should raise ERANGE for all strictly negative
>>> values ("-1" and below), which it currently does not in the GNU
>>> libc.
>>
>> I would agree, our strtoul is therefore neither ISO C or POSIX compliant.
>>
>> I would accept a patch to manual/arith.texi that documents this fact.
>> Alexandre Oliva is working on documenting compliance for glibc functions,
>> and he should have some macros to generate tables after each function
>> in which you can fill in compliance information e.g. POSIX: No.
>>
>>> Of course there is the possibility that it break some programs,
>>> even if it is a quite special case.
>>
>> That is the most difficult problem. Changing strtoul's behaviour
>> could cause all sorts of problems for existing programs. It is
>> unlikely we would change this behaviour to match the standard at
>> this point in time.
>>
>>> The set of programs where this change would make any difference is
>>> probably only a subset of the programs that have never been ported
>>> from GNU to Solaris/AIX/HPUX/etc.
>>
>> Correct, and this wouldn't be the only problem the would face during
>> porting.
>>
>>> In any case, the texinfo manual for strtoul is currently at least
>>> ambiguous to me. It should also mention the fact that strtoul is not
>>> portable unless the input string is known to represent a nonnegative
>>> number.
>>
>> I would be more than happy to review a patch to enhance the manual
>> to discuss the porting issue and that glibc's strtoul doesn't conform
>> with the standards.
>>
>> Care to create a patch for manual/arith.texi?
>>
>> Cheers,
>> Carlos.
>>