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

[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

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

[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

[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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

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

[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

[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