[Bug 269] Many compiler warnings with gcc 4.0
simon.s at apple.com
Wed Aug 31 22:18:14 CEST 2005
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.
char str[MAX_STRING_LEN]; // or sstr for signed
uint8_t data[MAX_STRING_LEN]; // or ustr for unsigned
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
>>> 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
> data, but that doesn't affect application code at all. Even
> whether or
> not glibc uses explicit unsigned char internally doesn't affect
> 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 *
> 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
> Forcing unsigned char would be a mistake, IMHO. I personally think
> are good. One man's ugly notation is another man's inline
> - List info/subscribe/unsubscribe? See http://www.freeradius.org/
More information about the Freeradius-Devel