fix <ctype.h> bugs on 64-bit machine

[Howland Craig D (Craig)]

One thought for a minor tweak:  since this is rather a unique construct,
add () to make more clear to the general population (i.e. later
maintainers) what is intended:
#define __ctype_lookup(__c) ((__ctype_ptr__+sizeof(""[__c]))[(int)__c])
                                                  ^       ^
(While most people probably know the general precedence rules, it's
hard to tell how many know that array dereferencing is higher than
sizeof.  And using "" as a shortcut to a character pointer is a bit
esoteric when coupled with [].  My compliments on a nice compact trick.)
 
I'm not normally a fan of () simply to make things easier to read for
people who don't know the precedence rules, but think that this is an
odd enough case to warrant considering it as a supplement to the
comments.
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Eric Blake
Sent: Monday, October 19, 2009 4:22 PM
To: newlib@sources.redhat.com
Subject: fix <ctype.h> bugs on 64-bit machine

Bruno Haible pointed out to me that on 64-bit machines, the use of
isalpha
(0x100000001LL) will cause an out-of-bounds array dereference, rather
than 
returning the correct result of isalpha(1).  32-bit machines are immune.
All 
of this stems from our QoI effort to warn about raw char arguments.  OK
to 
apply this fix?  I've verified that on 32-bit architectures, there is no

difference in the generated code, with or without optimization.  I've
also 
verified that 'gcc -Wall' still gives the desired warning.

...
+#define __ctype_lookup(__c) ((__ctype_ptr__+sizeof""[__c])[(int)__c])
...