[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: using the interfaces in ctype.h
(BTW, Terry, your address, tmm%mcci.com@localhost, isn't usable from mailers
which refuse to honour broken MX CNAMEs. MX target hosts _must_ be
canonical hostnames, i.e. host domain names with valid A records.
Your domain is liable to end up in the bogusmx.rfc-ignorant.org
On 18-Apr-08, at 1:19 PM, Terry Moore wrote:
Hmm. Back in the bad old days before C-89, casts didn't portably
guarantee that the result of casting was any different than what you
started with. So for example isspace((uchar) x) could be wrong if x
was > 0xFF.
I remember that the recommended practice (when using Whitesmiths C)
isspace(x & 255)
Indeed! Some implementations were so lame they didn't include the
mask in the implementation of the macro!
Oh oh, oops, the NetBSD implementations don't seem to include the mask
either! I didn't realized that! So sad. (Which may even mean they
violate the standards implication that they be able to safely accept
the value of EOF. FreeBSD, OpenBSD, and Darwin all seem to have much
better implementations, though they are all using proper (inline)
functions which makes it easier in some ways to do it right.)
I think a smart compiler should be able to do the modulo 256
reduction without actually masking, on most platforms. In any
event, when using modern compilers, the '&' will make everything an
int, and shouldn't cause any warnings. (Of course, the usual
#defines and so forth would normally be used instead of writing
Of course that's not going to work very well at all on machines where
a char is > 8 bits and a char is expected to have values > 0xFF. I
suppose one could hope for CHAR_BIT being defined correctly and create
the mask by shifting: ~(UINT_MAX << CHAR_BIT)
However for all it's failings, c89 is now pervasive on all unix and
unix-like systems that are still in any way interesting or useful for
ongoing work or play.
Hmmmm.... maybe though I should propose a patch to ctype.h that'll
make these macros safe even in face of inappropriate uses.
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |