[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Compiler warnings and signed vs. unsigned char, again

From: Ken Hornstein
Subject: Re: [Nmh-workers] Compiler warnings and signed vs. unsigned char, again
Date: Tue, 05 Feb 2013 11:19:11 -0500

>> How about this:  use unsigned char everywhere we can internally and
>> compile with gcc -funsigned-char/Solaris cc -xchar=u?
>I haven't tried it but I don't think having gcc use unsigned chars will
>silence it;  it's warning about the potential problem regardless of
>whether you've optioned it away this time.

According to the gcc man page on my system, under -funsigned-char:

           The type "char" is always a distinct type from each of "signed
           char" or "unsigned char", even though its behavior is always just
           like one of those two.

So since the prototype for functions like strcpy() and the like are "char",
in theory this would suppress the warnings.  But still ... I understand
David's reasons for wanting to use unsigned char (it feels more correct
to me as well), but I hate the idea of relying on specific C compiler
options.  For better or worse the POSIX API has pretty much mandated
that C character strings are "char", and casting the arguments to the
ctype macros seems to be the way the world deals with that.

>> Or maybe better::  we could funnel all C lib calls through macros that
>> have the casts.  It's not as bad as it sounds, just throw some perl at
>> it.
>It's as bad as it sounds for readability;  one doesn't have to think
>twice when reading calls to stdlib's functions.

I understand what things like getcpy() and mh_xmalloc() do for us, but
yeah, I'd rather stick with the regular C library calls as well when


reply via email to

[Prev in Thread] Current Thread [Next in Thread]