Re: Prohibited attachment type (was 0xdeadbeef)

Re: Prohibited attachment type (was 0xdeadbeef)

[Ray Lee]

On Wed, Jul 07, 2004 at 04:48:36AM -0700, tom st denis wrote:
> It will warn that 0xDEADBEEF is unsigned (which it isn't).

It is. Either read the standard, or read any of my email messages where
I quote the thing at you.

> Either there is an obscure clause in the C standard

Duuuude. The ANSI C standard is about 40 pages in the back of the K&R
second edition. You could read through it in a few hours. If you're
writing C code for more than just a pastime, you should do yourself a 
favor and read it. It's really not all that obscure or hard to
understand.

> [I personally don't have a copy of C99 nor do I plan on reading it
> for this]

Then how about you listen to people who have it, read it, and understand
it? Or how about at least believing that gcc is telling you the truth
when it warns that 0xdeadbeef is an unsigned constant?

Ray

Re: 0xdeadbeef vs 0xdeadbeefL

[tom st denis]

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


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Prohibited attachment type (was 0xdeadbeef)

[Richard B. Johnson]

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,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Prohibited attachment type (was 0xdeadbeef)

[tom st denis]

--- "Richard B. Johnson" <root@chaos.analogic.com> wrote:
> Tom is correct. A literal constant defaults to 'int'.

I did a bit more messing around with GCC and it seems in 

int x = 4;
if (x == 0xDEADBEEF) { ... }

It will warn that 0xDEADBEEF is unsigned (which it isn't).  Either
there is an obscure clause in the C standard [I personally don't have a
copy of C99 nor do I plan on reading it for this] or GCC cause an
incorrect diagnostic [which isn't in violation of the standards...]

Really GCC should just warn that 0xDEADBEEF is not a valid int constant
[for portability sake...].   It's simple, any constant > 16-bits should
have a UL/L or ULL/LL suffix.

Tom


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Prohibited attachment type (was 0xdeadbeef)

[Jakub Jelinek]

On Wed, Jul 07, 2004 at 04:48:36AM -0700, tom st denis wrote:
> --- "Richard B. Johnson" <root@chaos.analogic.com> wrote:
> > Tom is correct. A literal constant defaults to 'int'.
> 
> I did a bit more messing around with GCC and it seems in 
> 
> int x = 4;
> if (x == 0xDEADBEEF) { ... }
> 
> It will warn that 0xDEADBEEF is unsigned (which it isn't).  Either
> there is an obscure clause in the C standard [I personally don't have a
> copy of C99 nor do I plan on reading it for this] or GCC cause an
> incorrect diagnostic [which isn't in violation of the standards...]

It is certainly not obscure.
ISO C99 6.4.4.1#5 says:
The type of an integer constant is the first of the corresponding list in
which its value can be represented.

For Octal or Hexadecimal Constant and no suffix, the table lists:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int

Assuming 32-bit int, 0xdeadbeef has unsigned int type.

For Decimal Constant and no suffix, the table lists only:
int
long int
long long int
and thus assuming 32-bit int and 64-bit long, 3735928559 has long int type,
assuming 32-bit int, 32-bit long and 64-bit long long, 3735928559 has long
int type.

	Jakub

Re: Prohibited attachment type (was 0xdeadbeef)

[Pavel Machek]

Hi!

> It is certainly not obscure.
> ISO C99 6.4.4.1#5 says:
> The type of an integer constant is the first of the corresponding list in
> which its value can be represented.
> 
> For Octal or Hexadecimal Constant and no suffix, the table lists:
> int
> unsigned int
> long int
> unsigned long int
> long long int
> unsigned long long int
> 
> Assuming 32-bit int, 0xdeadbeef has unsigned int type.
> 
> For Decimal Constant and no suffix, the table lists only:
> int
> long int
> long long int
> and thus assuming 32-bit int and 64-bit long, 3735928559 has long int type,
> assuming 32-bit int, 32-bit long and 64-bit long long, 3735928559 has long
> int type.

Did you mean "long long int" at the end of last sentence?
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Prohibited attachment type (was 0xdeadbeef)

[Jakub Jelinek]

On Thu, Jul 08, 2004 at 07:52:04AM +0200, Pavel Machek wrote:
> > For Decimal Constant and no suffix, the table lists only:
> > int
> > long int
> > long long int
> > and thus assuming 32-bit int and 64-bit long, 3735928559 has long int type,
> > assuming 32-bit int, 32-bit long and 64-bit long long, 3735928559 has long
> > int type.
> 
> Did you mean "long long int" at the end of last sentence?

Obviously, that was a pasto.

	Jakub

Re: Prohibited attachment type (was 0xdeadbeef)

[R. J. Wysocki]

On Wednesday 07 of July 2004 13:18, Richard B. Johnson wrote:
> 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'.

Anyway, I think it's a good idea to put L wherever a constant is meant to be 
'long' and U wherever it's meant to be 'unsigned' etc., because it may be 
useful in debigging, eg.:

1) identifying wrong types being used (eg. int vs long, int vs unsigned, long 
vs unsigned long),
2) identifying typos (eg. 0x100000000 vs 0x10000000)

Yours,
rjw

-- 
Rafael J. Wysocki
----------------------------
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled.
					-- Richard P. Feynman