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?

[Ian Collins]

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]

Ian Collins <ia******@hotma il.comwrites:

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) ks***@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]

Keith Thompson wrote:

Ian Collins <ia******@hotma il.comwrites:

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

On Jan 24, 3:15 pm, Keith Thompson <[e-mail] 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]

In article <11************ **********@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lp******@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]

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]

Richard Tobin wrote:

In article <11************ **********@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lp******@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]

Yevgen Muntyan <mu************ ****@tamu.eduwr ites:

Richard Tobin wrote:

In article <11************ **********@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lp******@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) ks***@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]

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]

Keith Thompson wrote:

Yevgen Muntyan <mu************ ****@tamu.eduwr ites:

>Richard Tobin wrote:

>>In article <11************ **********@v45g 2000cwv.googleg roups.com>,
Lew Pitcher <lp******@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).