This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: fix <ctype.h> bugs on 64-bit machine
- From: "Howland Craig D (Craig)" <howland at LGSInnovations dot com>
- To: "Eric Blake" <ebb9 at byu dot net>, <newlib at sources dot redhat dot com>
- Date: Mon, 19 Oct 2009 17:43:30 -0400
- Subject: RE: fix <ctype.h> bugs on 64-bit machine
- References: A<loom.20091019T221118-115@post.gmane.org>
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])
...