Re: [OT] Re: 0xdeadbeef vs 0xdeadbeefL

From: Gabriel Paubert
Date: Thu Jul 08 2004 - 07:01:52 EST


On Thu, Jul 08, 2004 at 12:15:21PM +0100, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> On Thu, Jul 08, 2004 at 11:32:50AM +0200, Gabriel Paubert wrote:
>
> > Yes, I know and I use BK. But given the fact that you insult me for
> > better knowing C rules than you, I'm seriously considering switch
> > to subversion or arch instead.
> >
> > Argh, I've mentioned BK. There should be a Goldwin's law equivalent
> > for BitKeeper on lkml ;-)
>
> Godwin, surely?

Right, should have looked the name up.

>
> Anyway, if you think that suckversion authors knew C... Try to read their
> decoder/parser/whatever you call the code handling the data stream obtained
> from other end of connection. _Especially_ when it comes to signedness
> (of integers, mostly).

I did not read it, neither did I read BitKeeper's code for
obvious reasons.

>
> > - the aforementioned fgetc/getc/getchar issues.
>
> ... have nothing to do with char; getc() has more legitimate return values
> than char can represent.

Only one more, unless I missed something.

> No matter whether it's signed or unsigned, if
> you have
> ... char c;
> ...
> c = getc();
> you have a bug - Dirichlet Principle bites you anyway.

Indeed, but unfortunately you don't hit the problem with
pure ASCII on x86. That's one of the reasons for which
a lot of code ported to archs where char is unsigned by
default is simply compiled with -fsigned-char instead of
correcting the bugs.

The remaining case (char 0xff) is infrequent, at least
for Latin-[19] encodings in the languages I know, and
never happens with UTF-8 AFAICT.

Heck, even the 2.4 ppc kernel is compiled with
-fsigned-char, for $DEITY's sake.

Regards,
Gabriel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/