0xdeadbeef vs 0xdeadbeefL

0xdeadbeef vs 0xdeadbeefL

[David Eger]

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

-dte

Re: 0xdeadbeef vs 0xdeadbeefL

[tom st denis]

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

Consider the following...

#include <stdio.h>
int main(void)
{
  unsigned int x;
  x = 4;
  if (x < 0xdeadbeef) printf("hello");
  return 0;
}

If you run splint on that you get 

---
Splint 3.1.1 --- 13 Jun 2004

test2.c: (in function main)
test2.c:7:7: Operands of < have incompatible types (unsigned int, int):
                x < 0xdeadbeef
  To ignore signs in type comparisons use +ignoresigns

Finished checking --- 1 code warning
---

As far as I know splint follows C99 which means that it thinks the
constant is "int".  

Tom


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

Re: 0xdeadbeef vs 0xdeadbeefL

[viro]

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.

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

Re: 0xdeadbeef vs 0xdeadbeefL

[viro]

On Wed, Jul 07, 2004 at 04:10:28AM -0700, tom st denis wrote:
> > 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.

Correct.  And irrelevant.

> On some platforms 0xdeadbeef may be a valid int

Correct, but incomplete.

> Before you step down to belittle others I'd suggest you actually make
> sure you're right.  

Always do.

Exercise:
	1) what type does an integer constant 0xdeadbeef have on a platform
with INT_MAX equal to 0x7fffffff and UINT_MAX equal to 0xffffffff?
	2) when does the situation differ for integer constant 3735928559?

Oh, and do read the part of C standard in question.  Hint: extra restrictions
are placed on decimal constants, not on the octals and hexadecimals.

Re: 0xdeadbeef vs 0xdeadbeefL

[tom st denis]

--- viro@parcelfarce.linux.theplanet.co.uk wrote:
> Exercise:
> 	1) what type does an integer constant 0xdeadbeef have on a platform
> with INT_MAX equal to 0x7fffffff and UINT_MAX equal to 0xffffffff?
> 	2) when does the situation differ for integer constant 3735928559?
> 
> Oh, and do read the part of C standard in question.  Hint: extra
> restrictions
> are placed on decimal constants, not on the octals and hexadecimals.

That may be true but what does it hurt to imply the dimensions ahead of
time?  You meant an unsigned long constant so add the UL suffix.

Tom


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: 0xdeadbeef vs 0xdeadbeefL

[Gabriel Paubert]

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

Re: 0xdeadbeef vs 0xdeadbeefL

[tom st denis]

--- Gabriel Paubert <paubert@iram.es> wrote:
> > 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?

That goes right up there with, um nope.  The only reason why the
compiler doesn't error about it is because it's not an error.  Doesn't
mean it's right.

> On many platforms a "plain" char is unsigned. You can't write
> portable
> code without knowing this.

Um, actually "char" like "int" and "long" in C99 is signed.  So while
you can write 

signed int x = -3;

You don't have to.  in fact if you "have" to then your compiler is
broken.  Now I know that GCC offers "unsigned chars" but that's an
EXTENSION not part of the actual standard.  

You ought to distinguish "what my compiler does" with "what the
standard actually says".  If you want unsigned chars don't be lazy,
just write "unsigned char".  

As for writing portable code, um, jacka#!, BitKeeper, you know, that
thingy that hosts the Linux kernel?  Yeah it uses LibTomCrypt.  Why not
goto http://libtomcrypt.org and find out who the author is.  Oh yeah,
that would be me.  Why not email Wayne Scott [who has code in
LibTomCrypt btw...] and ask him about it?

Who elses uses LibTomCrypt?  Oh yeah, Sony, Gracenote, IBM [um Joy
Latten can chip in about that], Intel, various schools including
Harvard, Stanford, MIT, BYU, ...

I write code that builds on basically any box with GCC which includes
regular PCs, Macs, Gameboys, PS2, Suns, etc, etc, etc.  All without
changes....

Tom


		
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 

Re: 0xdeadbeef vs 0xdeadbeefL

[Christoph Hellwig]

On Wed, Jul 07, 2004 at 11:41:50AM -0700, tom st denis wrote:
> Um, actually "char" like "int" and "long" in C99 is signed.  So while
> you can write 
> 
> signed int x = -3;
> 
> You don't have to.  in fact if you "have" to then your compiler is
> broken.  Now I know that GCC offers "unsigned chars" but that's an
> EXTENSION not part of the actual standard.  

------------------------------ snip -----------------------------
 [#15]  The  three types char, signed char, and unsigned char
        are   collectively   called   the   character   types.   The
        implementation  shall  define  char  to have the same range,
	representation,  and  behavior  as  either  signed  char or
	unsigned char.35)
------------------------------ snip -----------------------------
 
> As for writing portable code, um, jacka#!, BitKeeper, you know, that
> thingy that hosts the Linux kernel?  Yeah it uses LibTomCrypt.  Why not
> goto http://libtomcrypt.org and find out who the author is.  Oh yeah,
> that would be me.  Why not email Wayne Scott [who has code in
> LibTomCrypt btw...] and ask him about it?
> 
> Who elses uses LibTomCrypt?  Oh yeah, Sony, Gracenote, IBM [um Joy
> Latten can chip in about that], Intel, various schools including
> Harvard, Stanford, MIT, BYU, ...

Tons of people use windows aswell.  You just showed that you don't know
C well enough, so maybe someone should better do an audit for your code ;-)

Re: 0xdeadbeef vs 0xdeadbeefL

[tom st denis]

--- Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 07, 2004 at 11:41:50AM -0700, tom st denis wrote:
> > Um, actually "char" like "int" and "long" in C99 is signed.  So
> while
> > you can write 
> > 
> > signed int x = -3;
> > 
> > You don't have to.  in fact if you "have" to then your compiler is
> > broken.  Now I know that GCC offers "unsigned chars" but that's an
> > EXTENSION not part of the actual standard.  
> 
> ------------------------------ snip -----------------------------
>  [#15]  The  three types char, signed char, and unsigned char
>         are   collectively   called   the   character   types.   The
>         implementation  shall  define  char  to have the same range,
> 	representation,  and  behavior  as  either  signed  char or
> 	unsigned char.35)
> ------------------------------ snip -----------------------------

Right.  Didn't know that.  Whoa.  So in essence "char" is not a safe
type.

> > As for writing portable code, um, jacka#!, BitKeeper, you know,
> that
> > thingy that hosts the Linux kernel?  Yeah it uses LibTomCrypt.  Why
> not
> > goto http://libtomcrypt.org and find out who the author is.  Oh
> yeah,
> > that would be me.  Why not email Wayne Scott [who has code in
> > LibTomCrypt btw...] and ask him about it?
> > 
> > Who elses uses LibTomCrypt?  Oh yeah, Sony, Gracenote, IBM [um Joy
> > Latten can chip in about that], Intel, various schools including
> > Harvard, Stanford, MIT, BYU, ...
> 
> Tons of people use windows aswell.  You just showed that you don't
> know
> C well enough, so maybe someone should better do an audit for your
> code ;-)

To be honest I didn't know that above.  That's why I'm always explicit.
 [btw my code builds in MSVC, BCC and ICC as well].

You don't need to know such details to be able to develop in C.  I'm
sure if you walked into [say] Redhat and gave an "on the spot C quiz"
about obscure rules they would fail.  You have to use some common sense
and apply the more relevant rules.  

Point is 0xDEADBEEFUL is just as simple to type and avoids any sort of
ambiguitity.  It means unsigned long.  No question about it.  No having
to refer to subsection 12 of paragraph 15 of section 23 of chapter 9 to
figure that out.

Why people are fighting over this is beyond me.  Fine, write it as
0xDEADBEEF see what the hell I care.  Honestly.  Open debate or what?  

And I don't need mr. Viro coming down off his mountain saying "oh you
fail it" because I don't know some obscure typing rule that I wouldn't
come accross because *** I AM NOT LAZY ***.  Hey mr. Viro what have you
contributed to the public domain lately?  Anything I can harp on in
public and abuse?  

Asshat.

Tom


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: 0xdeadbeef vs 0xdeadbeefL

[Harald Arnesen]

tom st denis <tomstdenis@yahoo.com> writes:

> Point is 0xDEADBEEFUL is just as simple to type and avoids any sort of
> ambiguitity.  It means unsigned long.  No question about it.  No having
> to refer to subsection 12 of paragraph 15 of section 23 of chapter 9 to
> figure that out.

If people write either 0XdeadbeefUL or 0xDEADBEEFul, fine. But this is a
place where character case really makes a difference in readibility-

> Why people are fighting over this is beyond me.  Fine, write it as
> 0xDEADBEEF see what the hell I care.  Honestly.  Open debate or what?  
>
> And I don't need mr. Viro coming down off his mountain saying "oh you
> fail it" because I don't know some obscure typing rule that I wouldn't
> come accross because *** I AM NOT LAZY ***.  Hey mr. Viro what have you
> contributed to the public domain lately?  Anything I can harp on in
> public and abuse?  

I think you will find that mr. Viro has contributed quite a lot :-)
-- 
Hilsen Harald.

Re: 0xdeadbeef vs 0xdeadbeefL

[David Weinehall]

On Wed, Jul 07, 2004 at 11:53:40AM -0700, tom st denis wrote:
[snip]
> And I don't need mr. Viro coming down off his mountain saying "oh you
> fail it" because I don't know some obscure typing rule that I wouldn't
> come accross because *** I AM NOT LAZY ***.  Hey mr. Viro what have you
> contributed to the public domain lately?  Anything I can harp on in
> public and abuse?  

Well, look at it this way...  Alexander Viro is one of very few persons
in the world that I'd trust enough to take unaudited code from and apply
to my own projects.

Oh, and you're using his works every day I suppose; he's behind most of
the VFS of the kernel.  Read the bloody changelogs for the kernel
instead of whining.


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

[OT] Re: 0xdeadbeef vs 0xdeadbeefL

[Gabriel Paubert]

On Wed, Jul 07, 2004 at 11:53:40AM -0700, tom st denis wrote:
> --- Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Jul 07, 2004 at 11:41:50AM -0700, tom st denis wrote:
> > > Um, actually "char" like "int" and "long" in C99 is signed.  So
> > while
> > > you can write 
> > > 
> > > signed int x = -3;
> > > 
> > > You don't have to.  in fact if you "have" to then your compiler is
> > > broken.  Now I know that GCC offers "unsigned chars" but that's an
> > > EXTENSION not part of the actual standard.  
> > 
> > ------------------------------ snip -----------------------------
> >  [#15]  The  three types char, signed char, and unsigned char
> >         are   collectively   called   the   character   types.   The
> >         implementation  shall  define  char  to have the same range,
> > 	representation,  and  behavior  as  either  signed  char or
> > 	unsigned char.35)
> > ------------------------------ snip -----------------------------
> 
> Right.  Didn't know that.  Whoa.  So in essence "char" is not a safe
> type.

It depends what you use it for, but it typically is not. 

The _very_ common mistake is assigning the result of fgetc/getc/getchar
(which are defined to return an _unsigned_ char cast to an int or EOF) 
to a plain char and then comparing it with -1 to check for EOF: 

1) it will never detect the EOF if the char is unsigned (PPC)

2) it will stop on a ÿ (that's an y with a diaeresis) on Intel. This
character is infrequent in the languages I use but it occasionally 
happens. 

Of course people who only use plain 7 bit ASCII never hit the bug,
but as soon as you go into Latin-$n encodings you may hit them (I'm 
only restricting myself to character sets based on the Latin alphabet). 

And no the solution is not to use -fsigned-char or -funsigned char
as an optin to GCC. Most of the time it only changes the kind of bugs 
that are hidden in the code, and 2) above is statistically harder to 
hit than 1).

> 
> > > As for writing portable code, um, jacka#!, BitKeeper, you know,
> > that
> > > thingy that hosts the Linux kernel?  Yeah it uses LibTomCrypt.  Why
> > not
> > > goto http://libtomcrypt.org and find out who the author is.  Oh
> > yeah,
> > > that would be me.  Why not email Wayne Scott [who has code in
> > > LibTomCrypt btw...] and ask him about it?

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

> > > 
> > > Who elses uses LibTomCrypt?  Oh yeah, Sony, Gracenote, IBM [um Joy
> > > Latten can chip in about that], Intel, various schools including
> > > Harvard, Stanford, MIT, BYU, ...
> > 
> > Tons of people use windows aswell.  You just showed that you don't
> > know
> > C well enough, so maybe someone should better do an audit for your
> > code ;-)
> 
> To be honest I didn't know that above.  That's why I'm always explicit.
>  [btw my code builds in MSVC, BCC and ICC as well].
> 
> You don't need to know such details to be able to develop in C.  I'm
> sure if you walked into [say] Redhat and gave an "on the spot C quiz"
> about obscure rules they would fail.  You have to use some common sense
> and apply the more relevant rules.  

Well, I consider the rules about plain char to be among the most
relevant, since I've been hit by them _way_ _more_ than about any 
other badly known C rule.

And finally, I'd personnaly prefer the char to be unsigned, for several
reasons:
- its name which suggests that it is an enumeration of symbols. 
- strcmp and friends do the comparisons using _unsigned_ char,
despite the fact that the prototype declare plain char parameters
- the aforementioned fgetc/getc/getchar issues.
  
  
BTW, this signed/unsigned mess is a reason for some weirdness like 
tables with 384 entries in libc/ctype/ctype.h:


/* These are defined in ctype-info.c.
   The declarations here must match those in localeinfo.h.

   In the thread-specific locale model (see `uselocale' in <locale.h>)
   we cannot use global variables for these as was done in the past.
   Instead, the following accessor functions return the address of
   each variable, which is local to the current thread if multithreaded.

   These point into arrays of 384, so they can be indexed by any `unsigned
   char' value [0,255]; by EOF (-1); or by any `signed char' value
   [-128,-1).  ISO C requires that the ctype functions work for `unsigned
   char' values and for EOF; we also support negative `signed char' values
   for broken old programs.  
   
 [snipped]

Not specifying the signedness of the char types is one of C's original
mistakes, and the one that statistically mostly affects me.

	Gabriel (the only good char is the unsigned char)
 

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

[viro]

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?

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

> - the aforementioned fgetc/getc/getchar issues.

... have nothing to do with char; getc() has more legitimate return values
than char can represent.  No matter whether it's signed or unsigned, if
you have
	... char c;
	...
	c = getc();
you have a bug - Dirichlet Principle bites you anyway.

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

[Gabriel Paubert]

On Thu, Jul 08, 2004 at 12:15:21PM +0100, viro@parcelfarce.linux.theplanet.co.uk 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

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

[Andries Brouwer]

On Thu, Jul 08, 2004 at 12:15:21PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:

> - Dirichlet Principle bites you anyway.

Ah, it took me a few seconds to reconstruct what principle
you are referring to.

I am used to seeing "Dirichlet Principle" in a context where
one wants to solve a boundary value problem for certain elliptic
partial differential equations. (Then the principle states,
roughly, that the unique solution is found by minimizing
some integral.)

You invoke what I am used to call the pigeonhole principle.

Andries

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

[Michael Driscoll]

On Thursday 08 July 2004 10:41, Andries Brouwer wrote:
> On Thu, Jul 08, 2004, viro@parcelfarce.linux.theplanet.co.uk:
> > - Dirichlet Principle bites you anyway.
>
> Ah, it took me a few seconds to reconstruct what principle
> you are referring to.

I'm sure that Al meant "Dirichlet's Box Principle" here, as you say.

http://mathworld.wolfram.com/DirichletsBoxPrinciple.html
vs.
http://mathworld.wolfram.com/DirichletsPrinciple.html

-- 
Michael Driscoll, fenris@ulfheim.net
"A noble spirit embiggens the smallest man" -- J. Springfield

Re: 0xdeadbeef vs 0xdeadbeefL

[Horst von Brand]

tom st denis <tomstdenis@yahoo.com> said:
> --- Gabriel Paubert <paubert@iram.es> wrote:

[...]

> > On many platforms a "plain" char is unsigned. You can't write
> > portable
> > code without knowing this.
> 
> Um, actually "char" like "int" and "long" in C99 is signed.

Nope. char is either an unsigned char or a signed char, which one is up to
the implementation, and the three types are distinct. The signed keyword
was introduced exactly for the corner case of an explicitly signed (not
unsigned, and not maybe signed) char.

>                                                             So while
> you can write 
> 
> signed int x = -3;
> 
> You don't have to.  in fact if you "have" to then your compiler is
> broken.  Now I know that GCC offers "unsigned chars" but that's an
> EXTENSION not part of the actual standard.  

Not an extension, in C for ever and ever.

> You ought to distinguish "what my compiler does" with "what the
> standard actually says".  If you want unsigned chars don't be lazy,
> just write "unsigned char".  

Right. Look at the standard, and then go back and rewrite to agree with C99
all the "standard conforming" C you have written. Should keep you away from
LKML for a while...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: 0xdeadbeef vs 0xdeadbeefL

[Andrew Rodland]

<posted & mailed>

tom st denis wrote:


> As for writing portable code, um, jacka#!, BitKeeper, you know, that
> thingy that hosts the Linux kernel?  Yeah it uses LibTomCrypt.  Why not
> goto http://libtomcrypt.org and find out who the author is.  Oh yeah,
> that would be me.  Why not email Wayne Scott [who has code in
> LibTomCrypt btw...] and ask him about it?
> 
> Who elses uses LibTomCrypt?  Oh yeah, Sony, Gracenote, IBM [um Joy
> Latten can chip in about that], Intel, various schools including
> Harvard, Stanford, MIT, BYU, ...

Thought the name looked familiar, now I figure out why. Ladies and
gentlemen, the Al Viro of sci.crypt has met the Al Viro of... Al Viro.

Re: 0xdeadbeef vs 0xdeadbeefL

[Richard B. Johnson]

On Tue, 6 Jul 2004, David Eger 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...
>
> -dte

Well if you put the 'name' so we could search for the reason.....
It probably is used for magic to initialize long-words. Without
the L, you may get a 'C' warning error because numbers default 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: 0xdeadbeef vs 0xdeadbeefL

[David Eger]

On Tue, Jul 06, 2004 at 08:38:53PM -0400, Richard B. Johnson wrote:
> On Tue, 6 Jul 2004, David Eger 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...
> 
> Well if you put the 'name' so we could search for the reason.....

The reason I ask is that I'm going on a cleaning spree of 

include/video/radeon.h

I was trying to debug my code figuring out which flags we were 
setting in GMC_GUI_MASTER_CNTL.  Now radeon.h does have lots of
#defines for what the bits mean, but they're all mixed up, e.g.:

#define GMC_DP_CONVERSION_TEMP_6500                0x00000000
#define GMC_DP_SRC_RECT                            0x02000000
#define GMC_DP_SRC_HOST                            0x03000000
#define GMC_DP_SRC_HOST_BYTEALIGN                  0x04000000
#define GMC_3D_FCN_EN_CLR                          0x00000000
#define GMC_3D_FCN_EN_SET                          0x08000000
#define GMC_DST_CLR_CMP_FCN_LEAVE                  0x00000000
#define GMC_DST_CLR_CMP_FCN_CLEAR                  0x10000000
#define GMC_AUX_CLIP_LEAVE                         0x00000000
#define GMC_AUX_CLIP_CLEAR                         0x20000000
#define GMC_WRITE_MASK_LEAVE                       0x00000000
#define GMC_WRITE_MASK_SET                         0x40000000
#define GMC_CLR_CMP_CNTL_DIS                       (1 << 28)
#define GMC_SRC_DATATYPE_COLOR                     (3 << 12)
#define ROP3_S                                     0x00cc0000
#define ROP3_SRCCOPY                               0x00cc0000
#define ROP3_P                                     0x00f00000
#define ROP3_PATCOPY                               0x00f00000
#define DP_SRC_SOURCE_MASK                         (7    << 24)
#define GMC_BRUSH_NONE                             (15   <<  4)
#define DP_SRC_SOURCE_MEMORY                       (2    << 24)
#define GMC_BRUSH_SOLIDCOLOR                       0x000000d0

This mish-mash makes it impossible to grep for '0x00f0' or 
'0x000000f0' and get the answer I want, as GMC_BRUSH_NONE isn't 
listed in such a form.  So I wrote a little script to standardize
the file, and I noticed that in other sections, we have #defines
like these:

// CLK_PIN_CNTL
#define CLK_PIN_CNTL__OSC_EN_MASK                          0x00000001L
#define CLK_PIN_CNTL__OSC_EN                               0x00000001L
#define CLK_PIN_CNTL__XTL_LOW_GAIN_MASK                    0x00000004L
#define CLK_PIN_CNTL__XTL_LOW_GAIN                         0x00000004L
#define CLK_PIN_CNTL__DONT_USE_XTALIN_MASK                 0x00000010L
#define CLK_PIN_CNTL__DONT_USE_XTALIN                      0x00000010L

As part of the standardization, my script strips the 'L' off
of the constant.  (It's the output of 'eval()'ing the #define in 
Python.)  I was really just wondering if this would break anyone's
code.

Invocation goes like this:

$ (stdlbdef.py | upsidedown.py | stdlbdef.py | upsidedown.py ) < radeon.h > radeon.h.2

Then all of the simple arithmetic #define's are aligned to a uniform
width of hex value within each block of #define's.

-dte

#!/usr/bin/python
#
#  stdlbdef.py
#
# Got a header file where someone has mixed up their constants 
#  willy-nilly, like this?
#
#define GMC_AUX_CLIP_LEAVE                         0x00000000
#define GMC_AUX_CLIP_CLEAR                         0x20000000
#define GMC_WRITE_MASK_LEAVE                       0x00000000
#define GMC_WRITE_MASK_SET                         0x40000000
#define GMC_CLR_CMP_CNTL_DIS                       (1 << 28)
#define GMC_SRC_DATATYPE_COLOR                     (3 << 12)
#
# This script will make them all nice constants... mmmm..

import string
import re
import sys

linesplitter = re.compile("^(?P<a>#define\s+[a-zA-Z0-9_]+\s+)(?P<b>.*)")
hexnum = re.compile("^0[xX][0-9a-fA-F]+$")

l = sys.stdin.readline()
lastsize = 2

while l:
        ma = linesplitter.search(l,0)
        if ma and ma.group("b"):
                exp = ma.group("b").rstrip()
                # process the line
                if hexnum.match(exp,0) and len(exp) >= lastsize:
                        lastsize = len(exp)
                        sys.stdout.write( l )
                else:
                        try:
                                num = eval(exp)
                                q = '0x%x' % num
                                if len(q) < lastsize:
                                        fs = '0x%%0%dx' % (lastsize - 2)
                                        q = fs % num
                                lastsize = len(q)
                                sys.stdout.write( '%s%s\n' % (ma.group("a"), q))
                        except:
                                sys.stdout.write( l )
        else:
                sys.stdout.write( l )
                lastsize = 2
        l = sys.stdin.readline()


#!/usr/bin/python
#
# upsidedown.py
#
#   prints out a file, line by line, starting with the last line, 
#    going to the first

import sys
l = sys.stdin.readlines()
l.reverse()
for i in l:
        sys.stdout.write(i)

Re: 0xdeadbeef vs 0xdeadbeefL

[Richard B. Johnson]

On Wed, 7 Jul 2004, David Eger wrote:

> On Tue, Jul 06, 2004 at 08:38:53PM -0400, Richard B. Johnson wrote:
> > On Tue, 6 Jul 2004, David Eger 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...
> >
> > Well if you put the 'name' so we could search for the reason.....
>
> The reason I ask is that I'm going on a cleaning spree of
>
> include/video/radeon.h
>
> I was trying to debug my code figuring out which flags we were
> setting in GMC_GUI_MASTER_CNTL.  Now radeon.h does have lots of
> #defines for what the bits mean, but they're all mixed up, e.g.:
>
> #define GMC_DP_CONVERSION_TEMP_6500                0x00000000
> #define GMC_DP_SRC_RECT                            0x02000000
> #define GMC_DP_SRC_HOST                            0x03000000
> #define GMC_DP_SRC_HOST_BYTEALIGN                  0x04000000

[SNIPPED...]

Yes, they are not pretty. I would suggest puting them in
order, but nothing else. As you can tell by the response,
you have tripped on a hornet's nest and they are attacking
anything in the area. I certainly would not remove 'L' from
any of those constants. The code will be exactly the same
when compiled, but there may be some diagnostic messages
and nasty-grams from kernel hackers.

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: 0xdeadbeef vs 0xdeadbeefL

[Ray Lee]

tom st denis quoted David Eger saying:

>> 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. 
> [...]
> However, by the standard 0xdeadbeef is not a valid unsigned 
> long constant.

I think you have a different standard than I do [1]. According to K&R,
2nd ed, section A2.5.1 (Integer Constants):

        The type of an integer depends on its form, value and suffix.
        [...] If it is unsuffixed octal or hexadecimal, it has the first
        possible of these types ["in which its value can be represented"
        -- from omitted]: int, unsigned int, long int, unsigned long
        int.

Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.

Ray

	[1] "The great thing about standards is that there are so many
	     of them to choose from."  Wish I could remember who said
	     that.

Re: 0xdeadbeef vs 0xdeadbeefL

[viro]

On Tue, Jul 06, 2004 at 07:05:01PM -0700, Ray Lee wrote:
> 	[1] "The great thing about standards is that there are so many
> 	     of them to choose from."  Wish I could remember who said
> 	     that.

AST and in this case it actually doesn't apply - everything from K&R
to C99 is in agreement here.

Re: 0xdeadbeef vs 0xdeadbeefL

[Alexandre Oliva]

On Jul  7, 2004, viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Tue, Jul 06, 2004 at 07:05:01PM -0700, Ray Lee wrote:
>> [1] "The great thing about standards is that there are so many
>> of them to choose from."  Wish I could remember who said
>> that.

> AST and in this case it actually doesn't apply - everything from K&R
> to C99 is in agreement here.

Are you sure?  I've seen K&R C compilers for 32-bit platforms in which
0xdeadbeef had type *signed* int, as opposed to unsigned int.  I
thought the preference for an unsigned type in this case was
introduced in ISO C90, but it might as well have been a bug in that
compiler.  Although I'm told other compilers display similar behavior.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: 0xdeadbeef vs 0xdeadbeefL

[Ray Lee]

On Tue, 2004-07-06 at 22:58, Alexandre Oliva wrote:
> Are you sure?  I've seen K&R C compilers for 32-bit platforms in which
> 0xdeadbeef had type *signed* int, as opposed to unsigned int.

K&R pre-ANSI (i.e., K&R first edition) allowed this. K&R second edition,
a.k.a. ANSI C clarifies this substantially, as per my previous two
messages on the topic.

> I thought the preference for an unsigned type in this case was
> introduced in ISO C90, but it might as well have been a bug in that
> compiler.  Although I'm told other compilers display similar behavior.

File a bug.

Ray

Re: 0xdeadbeef vs 0xdeadbeefL

[Alexandre Oliva]

On Jul  6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:

> Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.

Assuming ints are 32-bits wide.  They don't have to be.  They could be
as narrow as 16 bits, in which case the constant will have type long
or unsigned long (because long must be at least 32 bits), or they
could be wider than 32 bits, in which case the constant will be signed
int instead of unsigned int.  You might lose either way.  It's
probably safer to make it explicitly UL, except perhaps in
machine-specific files where the width of types is well-known.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: 0xdeadbeef vs 0xdeadbeefL

[Ray Lee]

On Tue, 2004-07-06 at 22:55, Alexandre Oliva wrote:
> On Jul  6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:
> 
> > Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
> 
> Assuming ints are 32-bits wide.  They don't have to be.

In which case the rest of that line that read:
	
	it has the first possible of these types ["in which its value
	can be represented" -- from omitted]: int, unsigned int, long
	int, unsigned long int.

...kicks in.

> or they could be wider than 32 bits, in which case the constant will
> be signed int instead of unsigned int.

Read that line again. This would only happen if the platform has no
unsigned 32 bit integer whatsoever. If you can point out one of those to
me that Linux runs on, then I'll concede the point. On any other
platform, the constant oct/hex int promotion rules will walk it up to a
32-bit unsigned before it hits the larger types.

Ray

Re: 0xdeadbeef vs 0xdeadbeefL

[viro]

On Wed, Jul 07, 2004 at 02:55:01AM -0300, Alexandre Oliva wrote:
> On Jul  6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:
> 
> > Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
> 
> Assuming ints are 32-bits wide.

ITYM "at least 32-bits wide".

>  They don't have to be.  They could be
> as narrow as 16 bits, in which case

... you would have no fscking chance to build Linux kernel on such platform
for $BIGNUM reasons.

Re: 0xdeadbeef vs 0xdeadbeefL

[Alexandre Oliva]

On Jul  7, 2004, viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Wed, Jul 07, 2004 at 02:55:01AM -0300, Alexandre Oliva wrote:
>> On Jul  6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:
>> 
>> > Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
>> 
>> Assuming ints are 32-bits wide.

> ITYM "at least 32-bits wide".

No, exactly 32-bits wide.  If they're wider, it's going to be signed
int.  If they're narrower, it's going to be long or unsigned long,
depending on how wide long is.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: 0xdeadbeef vs 0xdeadbeefL

[H. Peter Anvin]

Followup to:  <orn02cqs3u.fsf@livre.redhat.lsd.ic.unicamp.br>
By author:    Alexandre Oliva <aoliva@redhat.com>
In newsgroup: linux.dev.kernel
>
> On Jul  6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:
> 
> > Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
> 
> Assuming ints are 32-bits wide.  They don't have to be.  They could be
> as narrow as 16 bits, in which case the constant will have type long
> or unsigned long (because long must be at least 32 bits), or they
> could be wider than 32 bits, in which case the constant will be signed
> int instead of unsigned int.  You might lose either way.  It's
> probably safer to make it explicitly UL, except perhaps in
> machine-specific files where the width of types is well-known.
> 

If it runs Linux:

	CHAR_BIT == 8
	sizeof(int) == 4
	sizeof(void(*)()) == sizeof(void *)
	sizeof(long) == sizeof(void *)
	sizeof(long long) == 8
	(long)NULL == 0L

These assumptions are pretty ingrained in the Linux kernel.
	
	-hpa

Re: 0xdeadbeef vs 0xdeadbeefL

[Tomas Szepe]

On Jul-06 2004, Tue, 19:05 -0700
Ray Lee <ray-lk@madrabbit.org> wrote:

> According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
>
>         The type of an integer depends on its form, value and suffix.
>         [...] If it is unsuffixed octal or hexadecimal, it has the first
>         possible of these types ["in which its value can be represented"
>         -- from omitted]: int, unsigned int, long int, unsigned long
>         int.

Is it safe to assume that C99 compilers append "..., long long int,
unsigned long long int" to the list?

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: 0xdeadbeef vs 0xdeadbeefL

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Wed, 2004-07-07 09:30:59 +0200, Tomas Szepe <szepe@pinerecords.com>
wrote in message <20040707073059.GA20079@louise.pinerecords.com>:
> On Jul-06 2004, Tue, 19:05 -0700
> Ray Lee <ray-lk@madrabbit.org> wrote:
> > According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
> >
> >         The type of an integer depends on its form, value and suffix.
> >         [...] If it is unsuffixed octal or hexadecimal, it has the first
> >         possible of these types ["in which its value can be represented"
> >         -- from omitted]: int, unsigned int, long int, unsigned long
> >         int.
> 
> Is it safe to assume that C99 compilers append "..., long long int,
> unsigned long long int" to the list?

It is.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 0xdeadbeef vs 0xdeadbeefL

[H. Peter Anvin]

Followup to:  <20040707073059.GA20079@louise.pinerecords.com>
By author:    Tomas Szepe <szepe@pinerecords.com>
In newsgroup: linux.dev.kernel
>
> On Jul-06 2004, Tue, 19:05 -0700
> Ray Lee <ray-lk@madrabbit.org> wrote:
> 
> > According to K&R, 2nd ed, section A2.5.1 (Integer Constants):
> >
> >         The type of an integer depends on its form, value and suffix.
> >         [...] If it is unsuffixed octal or hexadecimal, it has the first
> >         possible of these types ["in which its value can be represented"
> >         -- from omitted]: int, unsigned int, long int, unsigned long
> >         int.
> 
> Is it safe to assume that C99 compilers append "..., long long int,
> unsigned long long int" to the list?
> 

Yes.

	-hpa