what is 0xFFFFFFF ?

[Flash Gordon]

Re: what is 0xFFFFFFF ?

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

<snip>

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

[Keith Thompson]

Re: what is 0xFFFFFFF ?

"David T. Ashley" <dta@e3ft.comwr ites:

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

The header is <limits.h>. If you care about the minimum and maximum
values for the predefined integer types, you really should know this.

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.

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.hdidn '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.hdoes exist, and it's silly not to use it.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Re: what is 0xFFFFFFF ?

"Lew Pitcher" <lpitcher@sympa tico.cawrites:
[...]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Clark S. Cox III]

Re: what is 0xFFFFFFF ?

David T. Ashley wrote:

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.

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

--
Clark S. Cox III
clarkcox3@gmail .com

[David T. Ashley]

Re: what is 0xFFFFFFF ?

"Keith Thompson" <kst-u@mib.orgwrote in message
news:lnd554gp3y .fsf@nuthaus.mi b.org...

"David T. Ashley" <dta@e3ft.comwr ites:
>
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.hdidn '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.hdoes 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.hseem s ... on
the border of being unnecessary. It is right on the border of my threshold
for being unnecessary.
--
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)

[Ian Collins]

Re: what is 0xFFFFFFF ?

David T. Ashley wrote:

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

Why a preprocessor constant?

Why not

const unsigned number_of_hairs _a_cat_might_ha ve = 87192;

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

Again, if it where an integer constant, your debugger or whatever would
be able to show you the value. Preprocessor constants are evil.

--
Ian Collins.

[Keith Thompson]

Re: what is 0xFFFFFFF ?

Ian Collins <ian-news@hotmail.co mwrites:

David T. Ashley wrote:

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:

Why a preprocessor constant?
>
Why not
>
const unsigned number_of_hairs _a_cat_might_ha ve = 87192;

Because an object declared as const can't be used in some contexts
where an appropriately defined macro can. For example, your
number_of_hairs _a_cat_might_ha ve can't be used as a case label:

switch(whatever ) {
case number_of_hairs _a_cat_might_ha ve: /* error */
...
}

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ian Collins]

Re: what is 0xFFFFFFF ?

Keith Thompson wrote:

Ian Collins <ian-news@hotmail.co mwrites:
>

>>David T. Ashley wrote:
>>

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

>>
>>Why a preprocessor constant?
>>
>>Why not
>>
>>const unsigned number_of_hairs _a_cat_might_ha ve = 87192;

>
>
Because an object declared as const can't be used in some contexts
where an appropriately defined macro can. For example, your
number_of_hairs _a_cat_might_ha ve can't be used as a case label:
>
switch(whatever ) {
case number_of_hairs _a_cat_might_ha ve: /* error */
...
}
>

I know, but it was appropriate in the context of this example.

--
Ian Collins.

[Lew Pitcher]

Re: what is 0xFFFFFFF ?



On Jan 24, 3:15 pm, Keith Thompson <k...@mib.orgwr ote:

"Lew Pitcher" <lpitc...@sympa tico.cawrites:[...]
>

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.

Note that I didn't say that it could /legally/ be used as an
initializer for a pointer.

Since the OP didn't present any code other than the #define, we (I)
have no way of knowing what the code that uses the macro looks like.
Conceivable, the code could contain
char *somewhere = (char *)INFINITY;
in which case, the code /would/ be using the macro as an initializer
for a pointer. Wrongly.

I /did/ say that what the macro was used for (and hence, the
replacement token, the 0xFFFFFFF) depended on the source code.

--
Lew

[Richard Tobin]

Re: what is 0xFFFFFFF ?

In article <1169686574.731 572.155930@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lpitcher@sympa tico.cawrote:

>Since the OP didn't present any code other than the #define, we (I)
>have no way of knowing what the code that uses the macro looks like.

Except for common sense.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Re: what is 0xFFFFFFF ?

Ian Collins wrote:

>

.... snip ...

>
Why a preprocessor constant?
>
Why not
>
const unsigned number_of_hairs _a_cat_might_ha ve = 87192;

This is a serious misnomer. It should be:

const unsigned number_of_hairs _my_cat_shed_to day = 87192;

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Yevgen Muntyan]

Re: what is 0xFFFFFFF ?

Richard Tobin wrote:

In article <1169686574.731 572.155930@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lpitcher@sympa tico.cawrote:
>

>Since the OP didn't present any code other than the #define, we (I)
>have no way of knowing what the code that uses the macro looks like.

>
Except for common sense.

Real code:

#define G_WIN32_MSG_HAN DLE 19981206

"HANDLE" there means "Windows HANDLE thing", a pointer.

Regards,
Yevgen

[Keith Thompson]

Re: what is 0xFFFFFFF ?

Yevgen Muntyan <muntyan.remove this@tamu.eduwr ites:

Richard Tobin wrote:

In article <1169686574.731 572.155930@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lpitcher@sympa tico.cawrote:

Since the OP didn't present any code other than the #define, we (I)
have no way of knowing what the code that uses the macro looks like.

Except for common sense.

>
Real code:
>
#define G_WIN32_MSG_HAN DLE 19981206
>
"HANDLE" there means "Windows HANDLE thing", a pointer.

The value 19981206 looks suspiciously like a date (December 6, 1998);
I doubt that that value would make sense as a pointer in Win32.

Um, what was your point?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Daniel Rudy]

Re: what is 0xFFFFFFF ?

At about the time of 1/24/2007 6:54 AM, Harald van Dijk stated the following:

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

Actually, it would be 268,435,455 as there are only 7 hex digits in that
declaration. It would be positive no matter signed or unsigned on a
32-bit platform because it's only 28 bits.



--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Yevgen Muntyan]

Re: what is 0xFFFFFFF ?

Keith Thompson wrote:

Yevgen Muntyan <muntyan.remove this@tamu.eduwr ites:

>Richard Tobin wrote:

>>In article <1169686574.731 572.155930@v45g 2000cwv.googleg roups.com>,
>>Lew Pitcher <lpitcher@sympa tico.cawrote:
>>>
>>>Since the OP didn't present any code other than the #define, we (I)
>>>have no way of knowing what the code that uses the macro looks like.
>>Except for common sense.

>Real code:
>>
>#define G_WIN32_MSG_HAN DLE 19981206
>>
>"HANDLE" there means "Windows HANDLE thing", a pointer.

>
The value 19981206 looks suspiciously like a date (December 6, 1998);
I doubt that that value would make sense as a pointer in Win32.
>
Um, what was your point?

Does common sense tell you that G_WIN32_MSG_HAN DLE is a pointer (namely
is to be used as a pointer)? Where it's used, pointers are in fact cast
to int, and then back to pointers, so int here makes perfect sense in
fact. But can you tell this just looking at the #define?

As to values which do or don't make sense as pointers, why should it
be a valid pointer? These guys are nice too: (Whatever*)1 or
(Whatever*)-1. Their sense exactly is that they aren't valid pointers
(on conventional implementations , blah blah blah).