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@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