[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: