[Bug 269] Many compiler warnings with gcc 4.0

[Steven Simon]

The casts are a mixed bag. They can be distracting, but they document  
expectations, as Frank pointed out.
I'll present another option, also a bit ugly, and see how it goes.
We could use a union that has accessors for each value type. The code  
would have to use the appropriate one for the attribute.
union {
char str[MAX_STRING_LEN];			// or sstr for signed
uint8_t data[MAX_STRING_LEN];		// or ustr for unsigned
} value;

Steve



On Aug 31, 2005, at 12:38 PM, Frank Cusack wrote:

> On August 31, 2005 4:47:16 PM +1000 Paul TBBle Hampson  
> <Paul.Hampson at Pobox.com> wrote:
>> On Tue, Aug 30, 2005 at 01:15:45PM -0700, Steven Simon wrote:
>>> I tend to think this is the wrong approach. By convention, C  
>>> strings  are
>>> signed and Pascal strings (I know, nobody uses them anymore) are   
>>> unsigned.
>>> If char defaults to unsigned, it could cause more problems  than  
>>> it solves.
>>> We want the compiler to tell us if we're mixing C- strings and  
>>> data buffers.
>
> Absolutely, but this only comes into play when promoting char to int,
> as is done with varargs functions, e.g. sprintf().  (There is no such
> thing as a char argument to a varargs function; all chars are promoted
> to int, and unsigned chars to unsigned ints.)
>
> One common place this happens is for debug output, when printing the
> contents of buffers.
>
> <http://www.freshsources.com/1994017B.HTM> is a good page describing
> the difference between signed and unsigned char.
>
>> Chars are unsigned on Linux PowerPC. I don't believe there's  
>> anything that
>> depends on chars being signed that doesn't explicitly declare  
>> such, as I ran
>> FreeRADIUS on LinuxPPC without issues for a few years. I think all
>> signed-char assumptions were therefore shaken out a fair while ago.
> ...
>
> To say that chars are unsigned on Linux PPC is meaningless.   
> Whether chars
> are signed or unsigned is up to the compiler.  Now it may be the  
> case that
> gcc on Linux PPC does treat char as unsigned, but I highly doubt it.
>
> Linux PPC itself may have lots of code that explicitly has unsigned  
> char
> data, but that doesn't affect application code at all.  Even  
> whether or
> not glibc uses explicit unsigned char internally doesn't affect  
> applications
> since behavior must still conform to the various standards.  Wherever
> char *'s are used, promotion isn't done so signed vs. unsigned doesn't
> matter.  (And current standards call for void * instead of char *  
> almost
> everywhere.)
>
> My point is that FR running successfully on Linux PPC, which may use
> unsigned char everywhere internally (I'll take your word on it) does
> not imply anything about how char might be treated in application  
> code.
>
> Forcing unsigned char would be a mistake, IMHO.  I personally think  
> casts
> are good.  One man's ugly notation is another man's inline  
> documentation.
>
> -frank
> - List info/subscribe/unsubscribe? See http://www.freeradius.org/ 
> list/devel.html