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