Re: gnome-pim: Cannot open user-cal.vcf or GnomeCard.gcrd on PPC
"C.M. Connelly" wrote:
> "AP" == Adam C Powell IV <hazelsct@mit.edu> 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.
Reply to: