Re: Prohibited attachment type (was 0xdeadbeef)

From: Richard B. Johnson (root_at_chaos.analogic.com)
Date: 07/07/04

  • Next message: Richard B. Johnson: "Re: 0xdeadbeef vs 0xdeadbeefL" 
    Date:	Wed, 7 Jul 2004 07:18:00 -0400 (EDT)
To: tom st denis <tomstdenis@yahoo.com>

    On Wed, 7 Jul 2004, 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
    > than max for int. in the 3rd case the expression is converted
    > implicitly to int before the assignment is performed which is why there
    > is no warning.
    >
    > Before you step down to belittle others I'd suggest you actually make
    > sure you're right.
    >
    > Tom
    >

    Tom is correct. A literal constant defaults to 'int'.

    Cheers,
    *** Johnson
    Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
                Note 96.31% of all statistics are fiction.

    -
    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/

  • Next message: Richard B. Johnson: "Re: 0xdeadbeef vs 0xdeadbeefL"