Re: strtoul(-1) discussion

[Fabrice Bauzac <libnoon at 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.
>>