Hi,

* Ivan Skytte Jørgensen wrote (2007-12-30 13:36):
>On Friday 28 December 2007 22:09:53 Thorsten Haude wrote:
>> * Tony Balinski wrote (2007-09-07 18:04):
>> >Another thing is the expression isalnum((int)*name). If char is
>> >signed (I think it is/was(?) with Sun's compiler), this can cause
>> >problems, especially with the old-fashioned macro implementation of
>> >ctype.h. Better to use isalnum((unsigned char)*name) instead to be
>> >explicit.
>>
>> Interesting, my book clearly calls for an int for ISO C. Why would the
>> cast be a problem in this case?
>
>plain char is signed (at least in gcc) on solaris. Casting to int causes sign 
>extension. Which means that the character 'æ' (230) will be treated as a 
>negative number indexing into the bogus area in ctype's tables (see post 
>2007-10-15 19:12).

So Solaris libc (?) is so broken that its isalnum() does not accepts
its own chars? I find it difficult to believe that nobody ever choked
on that before, and hard. (So option 2 most probably is true: I didn't
understand your explanation.)


>The use of <ctype.h> is likely to go away when implementing utf-8 support, so 
>it is probably best just to live with the ugly "unsigned char" casts :-/

Yeah, like that's going to happen anytime soon.

Anyway, I don't think warnings have to be removed at all cost, or that
casts should always document exactly what's righteous for any given
situation. A little text would be enough here


Thorsten                                                  Blackmail: Armory
-- 
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.
    - Jeremy S. Anderson

Attachment: pgptaqLAWHyIC.pgp
Description: PGP signature

-- 
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop

Reply via email to