"C.M. Connelly" wrote: > "AP" == Adam C Powell IV <[EMAIL PROTECTED]> writes: > > AP> lexGetc is returning 255 for EOF instead of -1. This is > AP> because lexLookAhead is calling int lexGeta(), which > AP> returns the value from char lexGetc(). In the cast from > AP> char to int, it gives 255 instead of -1, even though the > AP> char is not unsigned. On Intel and Alpha, it gives -1, > AP> which is the correct behavior (right?). > > No, it's not the ``correct'' behavior, it's the behavior exhibited > by some systems.
> It's not a compiler issue, it's a sloppy-coding issue. Assuming > that char is unsigned may be fine if you can guarantee that your > code will only ever run on a system that supports that behavior, > but the Linux world has grown beyond Intel and coding styles have > to change to reflect that. Truly portable code *cannot* include > assumptions about the behavior of the systems on which it may be > run. I guess this is due to ANSI C not defining the signedness for char (I assume it doesn't otherwise we wouldn't be having this discussion). Most built in C types default to signed (eg. int, short, long) and this is what most compilers implement for C. I guess it depends on the default system compiler. Yes, the _pure_ fix is to modify all source code that uses char to use a new abstract type of signed char or unsigned char. This is a practical nightmare but is achievable given enough time. The other solution is to specify the char type on the compiler command line (assuming the compiler has this flexibility). I am a big PowerPC fan but I would like to know the reasoning behind the Linux/PPC people choosing unsigned char as the default char type. Why go against the convention ? I hope there is a really good reason that will help progress the C programming environment to better things. Brendan Simon.
