"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. 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 [EMAIL PROTECTED] SHC, DS +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
