Thank you very much for this discussion. I have learned a great deal,
and will try in the future to avoid making assumptions about sign of a
char, and casting between char and int.
It seems the best fix to gnome-pim is the attached one-line patch, it
prevents the return from fgetc from being down
On Wed, Apr 12, 2000 at 10:22:59PM -0500, Jim Studt wrote:
> Brendan Simon. wrote
> > 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 re
Jim Studt wrote:
> Fortunately some wise soul extended the ARM compiler to print a warning
> when a `char' is compared to a negative constant. We collect these during
> the builds and list them over at...
> http://www.federated.com/~jim/arm/charhell.html
> ... there are only about 150 pac
Brendan Simon. wrote
> 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 bet
On Thu, 13 Apr 2000, Brendan J Simon wrote:
>
> 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 implemen
"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
I wrote
CMC> Assuming that char is unsigned may be fine if you can
when, of course, I meant to say that assuming that char is either
signed *or* unsigned is a bad idea. Whoops.
C.
P.S. If you want a signed char, you should declare it as `signed
char'; for an unsigned char, declare it as
"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 th
Hello,
I think I have the problem... it's a doozy. :-)
lexGetc is returning 255 for EOF instead of -1. This is because
lexLookAhead is calling int lexGeta(), which returns the value from char
lexGetc(). In the cast from char to int, it gives 255 instead of -1, even
though the char is not unsign
9 matches
Mail list logo
