what is 0xFFFFFFF ?

[Ian Collins]

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

 

[Keith Thompson]

Why a preprocessor constant?

Why not

const unsigned number_of_hairs_a_cat_might_have = 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_have can't be used as a case label:

switch(whatever) {
case number_of_hairs_a_cat_might_have: /* error */
...
}

 

[Ian Collins]

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_have can't be used as a case label:

switch(whatever) {
case number_of_hairs_a_cat_might_have: /* error */
...
}

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

 

[CBFalconer]

.... snip ...

Why a preprocessor constant?

Why not

const unsigned number_of_hairs_a_cat_might_have = 87192;

This is a serious misnomer. It should be:

const unsigned number_of_hairs_my_cat_shed_today = 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

 

[Lew Pitcher]

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.

 

[Richard Tobin]

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

 

[Yevgen Muntyan]

Except for common sense.

Real code:

#define G_WIN32_MSG_HANDLE 19981206

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

Regards,
Yevgen

 

[Keith Thompson]

Real code:

#define G_WIN32_MSG_HANDLE 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?

 

[Daniel Rudy]

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

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]

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

 

[Richard Tobin]

Except for common sense.

[/QUOTE]

Real code:

#define G_WIN32_MSG_HANDLE 19981206

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

If you say so. A "handle" can be various things in a computer
program: sometimes it's a pointer, sometimes it's not. But "infinity"
is not a sensible name for a pointer. It's reasonable to assume that
it isn't one.

-- Richard