This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC/PATCH]: transform builtin isdigit (okay with locales?)
> From: Dale Johannesen <dalej@apple.com>
>
> On Apr 8, 2004, at 2:07 PM, Paul Koning wrote:
>
> >>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
> >
> > Kaveh> I've seen in various source code people define isdigit(c) to
> > Kaveh> (unsigned)(c) - '0' <= 9
> >
> > Kaveh> I believe that even in the various dialects of EBCDIC, the
> > Kaveh> digits '0' to '9' are continuous and ascending. (And I don't
> > Kaveh> think we have any more EBCDIC targets anyway.) So I thought
> > Kaveh> perhaps it's okay to do this transformation inside GCC.
> >
> > Kaveh> Just to confirm though, this doesn't hold up in the face of
> > Kaveh> locales, right? So maybe not...
> >
> > If "isdigit" is defined to match a digit in the charset of the current
> > locale, then no -- what you describe wouldn't match Arabic digits, nor
> > Chinese/Japanese ones, never mind lesser known locales.
>
> But it isn't. "isdigit" is defined to match a decimal digit "as
> defined in 5.2.1" (c99) which requires the 10 familiar digits, and
> further requires they have values in consecutive ascending order.
> Locales don't affect this that I can see.
Confusing isn't it? :-)
I suspect there must be a third condition for the digits in order for
the transformation to be valid. In addition to digits being
contiguous and ascending, we would probably need to ensure a
consistent value for '0' in all "execution environments".
While I can define something like TARGET_DIGIT0 analogous to GCC's
TARGET_NEWLINE to handle EBCDIC's value, this appears to fall apart in
the face of locales which can be set at runtime. (Right?)
So I'm concluding that the transformation isn't valid for GCC to
perform.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu