Mail Archives: djgpp-workers/1998/02/09/08:13:54
Hans-Bernhard Broeker wrote:
>
> On Sun, 8 Feb 1998, Eli Zaretskii wrote:
>
> > Negative numbers from the signed char range do not belong to the
> > unsigned char range. People who use signed char for characters with
> > ASCII code beyond 127 write buggy code; they should use unsigned char
> > instead.
>
> Exactly. That's why Plauger says that you have to call them as in
> 'isalpha((unsigned char)c)' if there's any chance that c might be
> a 'negative char'.
If you already have had a look at the current implementation of is*
macros in the mean time you will have discovered that this exact way of
thinking is the foundation for the current buggy implementation.
> > I agree that it would be nice to have the ctype functions/macros
> > support the cases such as `(char)0x84', but if that support causes the
> > library to break ANSI compliance, and no viable solution could be
> > found, I have no problems with unsupporting it.
>
> You can support all input values except ((unsigned char)EOF), i.e.
> (char)0xff, by using a table of 256+128 entries. But then, correcting what
> is really incorrect use of these function for _almost_ all values isn't
> useful enough to pay the overhead.
The gnu libc does it this way. We can also do this in the is* macro's
without extending the size of the array, of course against (a minor)
performance cost.
> Heck, I'd even prefer an implementation that just abort()s if any netagive
> value other than EOF is passed in, with a message like 'isalpha() called
> incorrectly: argument < -1'. If I'm not totally mistaken, this'ld still be
> ANSI-compliant, but we'ld catch almost every erroneous use of the
> function, forcing the users to correct their programs. Such behaviour
> should be documented, of course, so the users get the problem explained by
> looking up the function in the libc docs.
I have been having this idea too, but not just only for the is* macro's.
If we could have two versions of the C library, one with no such
error/bug checking at all and one with a thorough checking against all
kind of idiocyncrasies. The latter one we would put in djdev*. Both
version should have the exact same behaviour when it concerns defined
behaviour (of course) and the latter one kindly ;) aborts the program
saying what the user did wrong. Since from what I see in the c.o.m.d ng
that djgpp is also used in educational environments, even at the basic
level, I think this would be no bad idea, even if it may seem opposed to
the 'spirit' of C.
What an idea for a minor release ;-)
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/
- Raw text -