Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34DF00A8.2BFC@rug.ac.be>
Date: Mon, 09 Feb 1998 14:12:08 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: djgpp-workers AT delorie DOT com
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, DJ Delorie <dj AT delorie DOT com>
Subject: Re: char != unsigned char... sometimes, sigh
References: <Pine DOT LNX DOT 3 DOT 93 DOT 980209133727 DOT 31635E-100000 AT acp3bf>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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 /          
   \ /-_-_-_-_-_-_/