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]

Re: what is 0xFFFFFFF ?

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.

--
Chris "electric hedgehog" Dollin
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Re: what is 0xFFFFFFF ?

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?

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]

Re: what is 0xFFFFFFF ?



On Jan 24, 9:43 am, "iskeletor" <zirvedo...@gma il.comwrote:

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

[iskeletor]

Re: what is 0xFFFFFFF ?

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

[Matthew Hicks]

Re: what is 0xFFFFFFF ?

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

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.

[Chris Dollin]

Re: what is 0xFFFFFFF ?

Harald van Dijk wrote:

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?

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

--
Chris "integral hedgehog" Dollin
"Who are you? What do you want?" /Babylon 5/

[Richard Tobin]

Re: what is 0xFFFFFFF ?

In article <1169650492.101 922.76290@h3g20 00cwc.googlegro ups.com>,
Harald van Dijk <truedfx@gmail. comwrote:

>#define INFINITY 0xFFFFFFF

>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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Chris Dollin]

Re: what is 0xFFFFFFF ?

Matthew Hicks wrote:

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.

--
Chris "electric hedgehog" Dollin
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

[Matthew Hicks]

Re: what is 0xFFFFFFF ?

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
>

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Re: what is 0xFFFFFFF ?

Chris Dollin wrote:

Harald van Dijk wrote:
>

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?

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

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]

Re: what is 0xFFFFFFF ?

Matthew Hicks wrote:

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

Re: what is 0xFFFFFFF ?

"Matthew Hicks" <mdhicks2@uiuc. eduwrote in message
news:b66e65218a e38c90db30c3d6e 88@news.ks.uiuc .edu...

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)(UINFINIT Y ^ (UINFINITY >1))
#define SMAX ((int)(UINFINIT Y >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.

--
David T. Ashley (dta@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Flash Gordon]

Re: what is 0xFFFFFFF ?

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

"Matthew Hicks" <mdhicks2@uiuc. eduwrote in message
news:b66e65218a e38c90db30c3d6e 88@news.ks.uiuc .edu...

>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)(UINFINIT Y ^ (UINFINITY >1))
#define SMAX ((int)(UINFINIT Y >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.
--
Flash Gordon

[David T. Ashley]

Re: what is 0xFFFFFFF ?

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:5kjk84x9ma .ln2@news.flash-gordon.me.uk...

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

>>
>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)(UINFINIT Y ^ (UINFINITY >1))
>#define SMAX ((int)(UINFINIT Y >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.

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.

--
David T. Ashley (dta@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)