This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strtoul(-1) discussion


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.
>

Attachment: strtoul-doc.git-patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]