Date: Tue, 10 Feb 1998 17:07:34 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: char != unsigned char... sometimes, sigh
In-Reply-To: <34E00C85.57DE@rug.ac.be>
Message-ID: <Pine.LNX.3.93.980210165433.32596E-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

On Tue, 10 Feb 1998, Vik Heyndrickx wrote:

> The following is an ANSI compliant behaving macro, and it supports also
> 'signed char'
> It yields reasonably efficient hard-code.
> 
> #define isupper(c) ({int t=(c);unsigned v;\
>                      ++t;\
>                      if(t<0)t+=256;\
>                      v=__dj_ctype_flags[t];\
>                      (v&__dj_ISUPPER)!=0;})

Which brings me to an idea: why should we provide is* _macros_ at all?  As
the DJGPP libc is for gcc, anyway, why not use 'extern inline' functions
instead? That'd save all the special casing and whatnot, and automatically
turn it into a function call whenever gcc thinks that's the better idea... 

I.e., why not put *this* in inlines/ctype.ha:

	extern int isupper(int c);
	extern inline int isupper(int c) {
	  return __dj_ctype_flags[c+1]&__dj_ISUPPER;
        }

> The following is an ANSI compliant behaving macro, it supports only
> 'unsigned char'.
> It yields the most efficient hard-code possible in many cases.
> 
> #define isupper(c) ({int t=(c);unsigned v;\
>                      ++t;\
>                      v=__dj_ctype_flags[t];\
>                      (v&__dj_ISUPPER)!=0;})
> 
> Note that ANY change you will make to these macro's will turn them less
> efficient. I know where I am talking about.

Could you unclose some of that knowledge? Like: why should your solution
with two temporary variables be more efficient than a simple

	((int)((__dj_ctype_flags[((int)(t))+1]&__dj_ISUPPER))

And how could a comparison ('!=0' at the end of your code) be more
efficient than a simple cast to int? The is* functions aren't required to
return only 1 or 0, after all, so there's no real need to translate '!=0'
to 1. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.