what is 0xFFFFFFF ?

[iskeletor]

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

 

[Chris Dollin]

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

It's a biggish [1] number, that's all.

[1] From the point of view of 32-bit machine integers in twos complement.
From any reasonable point of view, it's a peanut: not even 2pow32,
let alone (searches for a number) 10pow100.

 

[Guest]

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

0xFFFFFFFF is a hexadecimal integer constant. Its decimal value is
simply 4294967295. As far as C is concerned, that does not mean
infinity. Applications, however, may choose to have it mean exactly
that, just as they may choose 2 to mean infinity.

I don't know if you know what hexadecimal means. If you don't, a quick
search gives me
http://www.pcnineoneone.com/howto/hex1.html
as one possible introduction.

 

[Lew Pitcher]

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what?

Nope. It isn't ASCII

or is it a address that a pointer hold?
so adress of what?

It is unlikely that it is a pointer

Technically

#define INFINITY 0xFFFFFFF

tells the compiler to replace the token INFINITY with the token
0xFFFFFFF whenever the compiler encounters it in the source code. The
context of the source code statement that uses this INFINITY /
0xFFFFFFF token will give you "what it is".

0xFFFFFFF is taken as an integer value

It /might/ be used as the initializer for a pointer
It /might/ be used as the initializer for an integer data item

It depends on the context

HTH

 

[iskeletor]

I don't know if you know what hexadecimal means. If you don't, a quick
search gives me
http://www.pcnineoneone.com/howto/hex1.html
as one possible introduction.

thanx i know hexadecimal.I understood =))

 

[Chris Dollin]

0xFFFFFFFF is a hexadecimal integer constant.

Nitpick: the OP's text said 0xFFFFFFF, not 0xFFFFFFFF.
(One difference is that on a 32-bit-int implementation,
the OP's text will become a signed int literal but
yours will become an /unsigned/ int literal. If I
remember correctly.)

 

[Matthew Hicks]

Or it's a small negative number, -1. It's only a big positive number (what
it is supposed to represent given the context) if the system/program uses
32-bit unsigned ints.


---Matthew Hicks

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

It's a biggish [1] number, that's all.

[1] From the point of view of 32-bit machine integers in twos
complement.
From any reasonable point of view, it's a peanut: not even 2pow32,
let alone (searches for a number) 10pow100.

 

[Richard Tobin]

#define INFINITY 0xFFFFFFF

[/QUOTE]

0xFFFFFFFF is a hexadecimal integer constant. Its decimal value is
simply 4294967295.

The number was 0xFFFFFFF, not 0xFFFFFFFF. The latter might be a bad
choice as a large number on many current machines, since it would be
-1 if stored in an int. INT_MAX would be more portable.

-- Richard

 

[Chris Dollin]

Matthew Hicks wrote:

Please don't top-post. Thanks. Fixed.

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

It's a biggish [1] number, that's all.

[1] From the point of view of 32-bit machine integers in twos
complement.
From any reasonable point of view, it's a peanut: not even 2pow32,
let alone (searches for a number) 10pow100.

Or it's a small negative number, -1. It's only a big positive number (what
it is supposed to represent given the context) if the system/program uses
32-bit unsigned ints.

Count Fs.

It's positive anyway: if the value /was/ 0xFFFFFFFF, then on a 32-bit
implementation it will be an unsigned int, not a signed int. IIRC.

 

[Matthew Hicks]

Ignore my previous post as Mr. Tobin pointed out that there are only 7 hex
characters. On a side note, 0x7fffffff would probably be a better general
coice for infinity on most 32-bit machines.


---Matthew Hicks

Or it's a small negative number, -1. It's only a big positive number
(what it is supposed to represent given the context) if the
system/program uses 32-bit unsigned ints.

---Matthew Hicks

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer hold?
so adress of what?

It's a biggish [1] number, that's all.

[1] From the point of view of 32-bit machine integers in twos
complement.
From any reasonable point of view, it's a peanut: not even 2pow32,
let alone (searches for a number) 10pow100.

 

[Guest]

Nitpick: the OP's text said 0xFFFFFFF, not 0xFFFFFFFF.
(One difference is that on a 32-bit-int implementation,
the OP's text will become a signed int literal but
yours will become an /unsigned/ int literal. If I
remember correctly.)

Oops, quite right. In C99, 0xFFFFFFFF would be a signed long long (on a
32-bit-int 32-bit-long implementation), by the way.

 

[Matthew Hicks]

Please don't top-post. Thanks. Fixed.

iskeletor wrote:

in a program it is passing like that:

#define INFINITY 0xFFFFFFF

it is a ASCII code of what? or is it a address that a pointer
hold? so adress of what?

It's a biggish [1] number, that's all.

[1] From the point of view of 32-bit machine integers in twos
complement.
From any reasonable point of view, it's a peanut: not even 2pow32,
let alone (searches for a number) 10pow100.

Or it's a small negative number, -1. It's only a big positive number
(what it is supposed to represent given the context) if the
system/program uses 32-bit unsigned ints.

Count Fs.

It's positive anyway: if the value /was/ 0xFFFFFFFF, then on a 32-bit
implementation it will be an unsigned int, not a signed int. IIRC.

Only in logical test, you would have to be carefull if you used it in an
assignment operation.


---Matthew Hicks

 

[David T. Ashley]

Ignore my previous post as Mr. Tobin pointed out that there are only 7 hex
characters. On a side note, 0x7fffffff would probably be a better general
coice for infinity on most 32-bit machines.

Yes and no.

First, there are some constants in some system include file somewhere (never
figured out which one, or cared) which give the min and max values for the
types. This is the "right" way to define "infinity" in the sense you
intend.

However, ...

Those of us who have been around the block several times have figured out
that just about every machine in the world that we care about uses 2's
complement representation, and that the generalities defined in the Posix or
Single-Unix standard don't really apply in the world. Those of us who are
"in the know" might use something like this for the limits.

#define UINFINITY ((unsigned)-1)
#define SMIN ((int)(UINFINITY ^ (UINFINITY >> 1))
#define SMAX ((int)(UINFINITY >> 1))
/* The constants above should be proof to the over-generalizing lunatics
who write
** standards that you don't need to overcomplicate things. Note that the
** expressions above--assuming I didn't botch them--will work with any
** size of 2's complement integer.
*/

I don't claim that the expressions above are correct (I'm doing them
on-the-fly), but I'm sure you get the idea.

 

[Flash Gordon]

David T. Ashley wrote, On 24/01/07 16:07:

Yes and no.

First, there are some constants in some system include file somewhere (never
figured out which one, or cared) which give the min and max values for the
types. This is the "right" way to define "infinity" in the sense you
intend.

However, ...

Those of us who have been around the block several times have figured out
that just about every machine in the world that we care about uses 2's
complement representation, and that the generalities defined in the Posix or
Single-Unix standard don't really apply in the world. Those of us who are
"in the know" might use something like this for the limits.

#define UINFINITY ((unsigned)-1)
#define SMIN ((int)(UINFINITY ^ (UINFINITY >> 1))
#define SMAX ((int)(UINFINITY >> 1))
/* The constants above should be proof to the over-generalizing lunatics
who write
** standards that you don't need to overcomplicate things. Note that the
** expressions above--assuming I didn't botch them--will work with any
** size of 2's complement integer.
*/

#include <limits.h>

Wasn't that less work?

I don't claim that the expressions above are correct (I'm doing them
on-the-fly), but I'm sure you get the idea.

Those of us who have been around the block a good few times and actually
know the language know the header where it is defined and so don't have
to do them "on-the-fly" or dig them out of some custom header we have
written, or even worry about what representation is used. We just
include limits.h which is guaranteed to exist and use the defines there
in. Far less work and far more reliable.

Since you know they are in a header already I really can't see why you
would bother to write them yourself.

 

[David T. Ashley]

David T. Ashley wrote, On 24/01/07 16:07:

#include <limits.h>

Wasn't that less work?


Those of us who have been around the block a good few times and actually
know the language know the header where it is defined and so don't have to
do them "on-the-fly" or dig them out of some custom header we have
written, or even worry about what representation is used. We just include
limits.h which is guaranteed to exist and use the defines there in. Far
less work and far more reliable.

Since you know they are in a header already I really can't see why you
would bother to write them yourself.

I agree with you, actually.

The preprocessor constants of the style I mentioned were first spotted by me
in the GMP (not the verbatim same thing, but the style). I noticed at that
time that they were fairly clever, in that they worked for any size of
integer.

Those of us who have been around the block a good few times and actually
know the language know the header where it is defined and so don't have to
do them "on-the-fly" or dig them out of some custom header we have
written, or even worry about what representation is used. We just include
limits.h which is guaranteed to exist and use the defines there in. Far
less work and far more reliable.

I've never actually seen a machine with an integer representation other than
2's complement. I'm not sure I could write portable code for such a
machine. I'm not sure I'd want to. With integers, knowledge of the
representation is baked into the way I think.

For example:

<BEGIN>
unsigned msb, lsb, thing_to_add;

lsb += thing_to_add;

if (lsb < thing_to_add)
msb++;
<END>

The code above works because it makes assumptions about how the integer is
represented and what will happen if you add too much to it. I don't really
want to program on machines where those fundamental assumptions about 2's
complement integer arithmetic don't hold.

 

[Flash Gordon]

David T. Ashley wrote, On 24/01/07 18:54:

I've never actually seen a machine with an integer representation other than
2's complement. I'm not sure I could write portable code for such a
machine. I'm not sure I'd want to. With integers, knowledge of the
representation is baked into the way I think.

A lot of the time it makes no difference. Also, sometimes it is worth
making non-portable assumptions.

For example:

<BEGIN>
unsigned msb, lsb, thing_to_add;

lsb += thing_to_add;

if (lsb < thing_to_add)
msb++;
<END>

The code above works because it makes assumptions about how the integer is
represented and what will happen if you add too much to it.

Actually it does *not* depend on the representation for at least two
reasons.
1) As you have declared the variables as unsigned it makes no difference
which representation is used for signed arithmetic.
2) The C standard defined arithmetic on unsigned integers as wrapping in
the way you seem to expect. By the way, it defines the wrapping as not
being an overflow, a subtle point but important when reading the standard.

> I don't really
want to program on machines where those fundamental assumptions about 2's
complement integer arithmetic don't hold.

I've written code that depended on signed integers wrapping on overflow.
In the situation it was not unreasonable, but with hindsight I could
have done it using unsigned int instead and sidestepped the problem.
Some algorithms would have required a little tweaking, but nothing
difficult. I can't think of anything I have written since I left
assembler behind that depended on 2s complement though, apart from
reading numbers from an interface where the interface defined they were
2s complement.

 

[Keith Thompson]

Yes and no.

First, there are some constants in some system include file somewhere (never
figured out which one, or cared) which give the min and max values for the
types. This is the "right" way to define "infinity" in the sense you
intend.

However, ...

Those of us who have been around the block several times have figured out
that just about every machine in the world that we care about uses 2's
complement representation, and that the generalities defined in the Posix or
Single-Unix standard don't really apply in the world. Those of us who are
"in the know" might use something like this for the limits.

#define UINFINITY ((unsigned)-1)
#define SMIN ((int)(UINFINITY ^ (UINFINITY >> 1))
#define SMAX ((int)(UINFINITY >> 1))
/* The constants above should be proof to the over-generalizing lunatics
who write
** standards that you don't need to overcomplicate things. Note that the
** expressions above--assuming I didn't botch them--will work with any
** size of 2's complement integer.
*/

I don't claim that the expressions above are correct (I'm doing them
on-the-fly), but I'm sure you get the idea.

You need another ')' at the end of the definition of SMIN.

But I fail to see how this proves that "you don't need to
overcomplicate things". It's *much* simpler to add a

#include <limits.h>

to the top of your source file and use INT_MIN, INT_MAX, and UINT_MAX.
I don't care, or need to care, what tricks are used to define them; I
know that they'l give me the correct values. And I don't have to care
whether the system uses two's complement or not.

Sure, if <limits.h> didn't exist, I might write something like the
above and live with the fact that it only works for two's complement
(assuming that's true; I haven't analyzed your definitions). But
<limits.h> does exist, and it's silly not to use it.

 

[Keith Thompson]

0xFFFFFFF is taken as an integer value

It /might/ be used as the initializer for a pointer
It /might/ be used as the initializer for an integer data item

It depends on the context

0xFFFFFFF cannot be used as the initializer for a pointer unless it's
explicitly converted. There is no implicit integer-to-pointer
conversion except for the special case of null pointer constants.

 

[Clark S. Cox III]

I've never actually seen a machine with an integer representation other than
2's complement. I'm not sure I could write portable code for such a
machine. I'm not sure I'd want to. With integers, knowledge of the
representation is baked into the way I think.

For example:

<BEGIN>
unsigned msb, lsb, thing_to_add;

lsb += thing_to_add;

if (lsb < thing_to_add)
msb++;
<END>

The code above works because it makes assumptions about how the integer is
represented and what will happen if you add too much to it.

No, it doesn't make any such assumptions. The above code will work on
*any* conforming C implementation (because you are using unsigned
types). When you work with unsigned integers, the representation of
signed integers (and what happens when they overflow) is irrelevant.

 

[David T. Ashley]

But I fail to see how this proves that "you don't need to
overcomplicate things". It's *much* simpler to add a

#include <limits.h>

to the top of your source file and use INT_MIN, INT_MAX, and UINT_MAX.
I don't care, or need to care, what tricks are used to define them; I
know that they'l give me the correct values. And I don't have to care
whether the system uses two's complement or not.

Sure, if <limits.h> didn't exist, I might write something like the
above and live with the fact that it only works for two's complement
(assuming that's true; I haven't analyzed your definitions). But
<limits.h> does exist, and it's silly not to use it.

My arguments about complication come from some of the prohibitions on "magic
numbers". I've been blasted all the time for code like:

if (x > 87192) /* Number of hairs a cat might have. */
{

My counter-argument is that the only time it makes sense to define something
as a preprocessor constant is if:

a)There is some special symbolic clarity (bits in a hardware control
register, for example), OR

b)The constant appears in more than one place, AND

c)The occurrences are linked in a way where if one changes, the others must
change, too.

If those conditions aren't met, it just doesn't matter. I'm neither for or
against it.

Mentally (and maybe I was having a low-caffeine moment), I saw a bit of that
in this discussion.

Integer size and max values of integers and so on are part of the "ether"
(i.e. the environment). Why define a special constant for the maximum when
you can use something like ((unsigned) -1)? What special benefit is there?

Some of the code I've seen in my time has made a lot of work for me. For
example, I've seen stuff like:

if (x > UINT8_TWO)
{

If I'm going after a nebulous bug, it means that every time I see something
like that I have to verify the symbol the preprocessor is using. It is
unnecessary work.

It is simpler to say:

if (x > 2)
{

On a two's-complement machine, some of the stuff in <limits.h> seems ... on
the border of being unnecessary. It is right on the border of my threshold
for being unnecessary.