This is the mail archive of the
mailing list for the newlib project.
Re: problematic document for isascii(3)
- From: ntysdd <ntysdd at gmail dot com>
- To: Eric Blake <eblake at redhat dot com>
- Cc: newlib at sourceware dot org
- Date: Fri, 24 May 2013 16:23:06 +0800
- Subject: Re: problematic document for isascii(3)
- References: <CADk2T0O2A8Zd1DQdMdHYFChrDNcKkbRouZ47hTJR_KKs6pfvUA at mail dot gmail dot com> <519E26D3 dot 4020101 at redhat dot com>
The POSIX wording seems strange to me.
`The isdigit() and isdigit_l() functions shall test whether c is a
character of class digit in the current locale, or in the locale
represented by locale, respectively.'
But the ansi draft says:
`The only functions in $4.3 whose behavior is not affected by the
current locale are isdigit and isxdigit .'
2013/5/23 Eric Blake <firstname.lastname@example.org>:
> On 05/23/2013 07:21 AM, ntysdd wrote:
>> I found something buggy in the document.
>> The doc says "`isascii' is ANSI C", but it isn't.
>> It is a BSD extension.
> Actually, it is also POSIX, but you are correct that it is not C.
>> Also the doc for isdigit says
>> "It is defined only when `isascii'(C) is true or C is EOF."
> This is a lie; isascii(128) returns false, but isdigit(128) is well=defined.
>> But isdigit is ANSI C so it should not rely on isascii.
>> And after reading the ansi draft, I think isdigit is defined
>> for anything representable as an unsigned char (plus EOF).
> Correct, that is also the POSIX wording:
>> By the way, the doc says isdigit is a macro using a table.
>> I don't think it need be implemented in this way because
>> something like '0' <= C && C<='9' is good enough.
> That's still a table lookup, of sorts. The implementation can do
> whatever it wants under the hood, as long as the as-if rule is honored
> and you get the same results.
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org