Re: gnome-pim: Cannot open user-cal.vcf or GnomeCard.gcrd on PPC
"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.
AP> This is obviously not a gnome-pim problem, so I'm closing
AP> this bug. This would be a compiler issue, right? Until
AP> this is fixed, it would appear that everything using bison
AP> to parse files is broken on PPC and ARM.
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.
C.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly c@eskimo.com SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Reply to: