Re: 0xdeadbeef vs 0xdeadbeefL
From: Gabriel Paubert (paubert_at_iram.es)
Date: 07/07/04
- Previous message: Vojtech Pavlik: "Re: 2.6.7-mm6"
- In reply to: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Next in thread: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Reply: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 7 Jul 2004 18:30:49 +0200 To: tom st denis <tomstdenis@yahoo.com>
On Wed, Jul 07, 2004 at 04:10:28AM -0700, tom st denis wrote:
> --- viro@parcelfarce.linux.theplanet.co.uk wrote:
> > On Tue, Jul 06, 2004 at 05:06:12PM -0700, tom st denis wrote:
> > > --- David Eger <eger@havoc.gtf.org> wrote:
> > > > Is there a reason to add the 'L' to such a 32-bit constant like
> > this?
> > > > There doesn't seem a great rhyme to it in the headers...
> > >
> > > IIRC it should have the L [probably UL instead] since numerical
> > > constants are of type ``int'' by default.
> > >
> > > Normally this isn't a problem since int == long on most platforms
> > that
> > > run Linux. However, by the standard 0xdeadbeef is not a valid
> > unsigned
> > > long constant.
> >
> > ... and that would be your F for C101. Suggested remedial reading
> > before
> > you take the test again: any textbook on C, section describing
> > integer
> > constants; alternatively, you can look it up in any revision of C
> > standard.
> > Pay attention to difference in the set of acceptable types for
> > decimal
> > and heaxdecimal constants.
>
> You're f'ing kidding me right? Dude, I write portable ISO C source
> code for a living. My code has been built on dozens and dozens of
> platforms **WITHOUT** changes. I know what I'm talking about.
>
> 0x01, 1 are 01 all **int** constants.
>
> On some platforms 0xdeadbeef may be a valid int, in most cases the
> compiler won't diagnostic it. splint thought it was worth mentioning
> which is why I replied.
>
> In fact GCC has odd behaviour. It will diagnostic
>
> char x = 0xFF;
>
> and
>
> int x = 0xFFFFFFFFULL;
>
> But not
>
> int x = 0xFFFFFFFF;
>
> [with --std=c99 -pedantic -O2 -Wall -W]
>
> So I'd say it thinks that all of the constants are "int". In this case
> 0xFF is greater than 127 [max for char] and 0xFFFFFFFFFFULL is larger
You are aware that this statement is plainly and simply wrong,
aren't you?
On many platforms a "plain" char is unsigned. You can't write portable
code without knowing this.
>
> Before you step down to belittle others I'd suggest you actually make
> sure you're right.
Ditto.
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Vojtech Pavlik: "Re: 2.6.7-mm6"
- In reply to: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Next in thread: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Reply: tom st denis: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
