int/unsigned long * idiocy

[Christopher Benson-Manica]

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

(both of which should be valid according to a certain unnamed website)

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not). This
isn't really a question, but just a humorous look at how much fun
dealing with this unnamed setup can be. Comments are, of course,
welcome.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Dan Pop]

In <c2**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

(both of which should be valid according to a certain unnamed website)

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not). This
isn't really a question, but just a humorous look at how much fun
dealing with this unnamed setup can be. Comments are, of course,
welcome.

The implementor, obviously, never tried to see if PIPE_NOWAIT works.
Why should he bother, when the customers can do the job, as well? ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[nrk]

Christopher Benson-Manica wrote:

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

(both of which should be valid according to a certain unnamed website)

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not). This
isn't really a question, but just a humorous look at how much fun
dealing with this unnamed setup can be. Comments are, of course,
welcome.

It is quite obvious which platform/setup you're talking about. It is
equally clear that you've either:
a) Misread the documentation
or
b) Read documentation that is out of date or incorrect.

http://msdn.microsoft.com/library/de...andlestate.asp

Reading that seems to indicate that you need a local unsigned long (or
better yet, DWORD) that can contain the constants defined. It is not
explicitly mentioned, but it is quite clear what is expected. The notation
says LPDWORD is long pointer to double word. Further, even if the
documentation was unclear, the provided example is crystal clear on this
issue. It is also clear from the documentation that you would bitwise or
constants from the two tables to achieve combinations of read and blocking
modes.

This is quite normal with many such system calls that take flags (for
instance, open, creat, fcntl etc.). Even if the documentation was
incorrect, this much can be reasonably inferred by someone with more than a
passing familiarity with C and the system in question.

-nrk.

--
Remove devnull for email

[Erik de Castro Lopo]

Christopher Benson-Manica wrote:

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

(both of which should be valid according to a certain unnamed website)

Proof yet again that said unamed company has a room full
of monkeys sitting in front of computers.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
From Time magazine, "Numbers" section:
$5 million: Estimated annual cost for a 10-year program that
would identify large asteroids most threatening
to earth.
$75 million: Budget for "Deep Impact", a film about the
devastation caused when a comet hits earth.

[Ben Pfaff]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

As I read the unnamed website, the proper invocation is roughly
unsigned long mode = PIPE_(NO)WAIT;
SetNamedPipeHandleState(..., &mode, ...);
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Christopher Benson-Manica]

Ben Pfaff <bl*@cs.stanford.edu> spoke thus:

As I read the unnamed website, the proper invocation is roughly
unsigned long mode = PIPE_(NO)WAIT;
SetNamedPipeHandleState(..., &mode, ...);

I guess the "big" thing to do is to admit that I'm a moron, although I
still find that invocation to be annoying. Oh well.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Robert Wessel]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote in message news:<c2**********@chessie.cirr.com>...

I have, in a certain unnamed header file, the following:

#define PIPE_WAIT 0x00000000
#define PIPE_NOWAIT 0x00000001

and a function that the compiler believes has the following prototype:

__stdcall SetNamedPipeHandleState(void *,unsigned long *,
unsigned long *,unsigned long *); /* nonstandard calling convention */

The (unnamed) compiler is perfectly happy with

SetNamedPipeHandleState( NULL, PIPE_WAIT, NULL, NULL );

but has a temper tantrum over

SetNamedPipeHandleState( NULL, PIPE_NOWAIT, NULL, NULL );

(both of which should be valid according to a certain unnamed website)

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not). This
isn't really a question, but just a humorous look at how much fun
dealing with this unnamed setup can be. Comments are, of course,
welcome.

I'm baffled. You're misusing the function (the function really does
take pointers to DWORDs, aka unsigned longs, not the values directly),
and you're complaining that you get a compilation error? Or are you
complaining that MS choose to use zero as one of the PIPE_xxxx
constants?

[anony*mouse]

> Of course, what's happening here is clear (0x00000000 is NULL, and

thus compatible with unsigned long *, while 0x00000001 is not).

Surprisingly enough, MSVC does accept 0 or even 0L as NULL in C
language code. I wonder how common this is in other implementations.
It is not accepted in LCC-WIN32. What are peoples' preferences on
this? Should zero be accepted as NULL?

Sample code is provided in a link from the doc page for the specified
function.
Note that PIPE_NOWAIT is obsolete and should not be used. Use
overlapped IO instead. A read mode must also be provided.

dwMode = PIPE_READMODE_MESSAGE | PIPE_WAIT;
fSuccess = SetNamedPipeHandleState(
hPipe,    // pipe handle
&dwMode,  // new pipe mode
NULL,     // don't set maximum bytes
NULL);    // don't set maximum time
 

[pete]

anony*mouse wrote:

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not).

Surprisingly enough, MSVC does accept 0 or even 0L as NULL in C
language code. I wonder how common this is in other implementations.
It is not accepted in LCC-WIN32. What are peoples' preferences on
this? Should zero be accepted as NULL?

A constant with integer type and zero value,
is a null pointer constant.
When zero is used in a pointer context, zero equals NULL.
The type of NULL may be either (void*) or any integer type.

--
pete

[Richard Bos]

an*********@subdimension.com (anony*mouse) wrote:

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not).
Surprisingly enough, MSVC does accept 0 or even 0L as NULL in C
language code.

No kidding.
I wonder how common this is in other implementations.
It should be 100% common, since it is correct.
It is not accepted in LCC-WIN32.
Then LCC-WIN32 is not a C implementation, the way you used it.
What are peoples' preferences on
this? Should zero be accepted as NULL?

Preferences are immaterial. The Standard demands that any integral
constant with value 0 is a null pointer constant, and therefore a
correct definition of NULL.

Richard

[pete]

pete wrote:

anony*mouse wrote:

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not).

Surprisingly enough, MSVC does accept 0 or even 0L as NULL in C
language code. I wonder how common this is in other implementations.
It is not accepted in LCC-WIN32. What are peoples' preferences on
this? Should zero be accepted as NULL?

A constant with integer type and zero value,
is a null pointer constant.
When zero is used in a pointer context, zero equals NULL.

That's for constants only. An integer object with value zero,
is not a null pointer constant,
and has no meaning in a pointer context.

--
pete

[Dan Pop]

In <b6**************************@posting.google.com > an*********@subdimension.com (anony*mouse) writes:

Of course, what's happening here is clear (0x00000000 is NULL, and
thus compatible with unsigned long *, while 0x00000001 is not).
Surprisingly enough, MSVC does accept 0 or even 0L as NULL in C
language code. I wonder how common this is in other implementations.

It is required by the C standard.
It is not accepted in LCC-WIN32.
Then, this compiler is broken.
What are peoples' preferences on this? Should zero be accepted as NULL?

It shouldn't, but since the C standard says otherwise, our preferences
don't matter.

The right thing would be to introduce the __null (or _Null) keyword
as the *only* null pointer constant and require than NULL expands
to it. This won't break any properly written C code, that *always*
uses NULL when it needs a null pointer constant.

If such a change would be ever made, a two step approach will be needed:
C0x would introduce __null and deprecate all the other null pointer
constants. C1x could then remove all the other null pointer constants,
thus giving people plenty of time to fix their code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <GQ*****************@nwrddc02.gnilink.net> nrk <ra*********@devnull.verizon.net> writes:

This is quite normal with many such system calls that take flags (for
instance, open, creat, fcntl etc.).

Except that these functions don't take pointers to flags, they just take
the flags. I have yet to figure a good reason for requiring a pointer
to flags, unless the function is supposed to modify the user specified
flags (which would be really weird, as an API design).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[nrk]

Dan Pop wrote:

In <GQ*****************@nwrddc02.gnilink.net> nrk
<ra*********@devnull.verizon.net> writes:

This is quite normal with many such system calls that take flags (for
instance, open, creat, fcntl etc.).
Except that these functions don't take pointers to flags, they just take
the flags. I have yet to figure a good reason for requiring a pointer
to flags, unless the function is supposed to modify the user specified
flags (which would be really weird, as an API design).

You're right, that is a difference. I believe that the function in question
has a counterpart Get* function that needs a pointer. Maybe they just used
a pointer for the Set* as well just for symmetry in the API (not saying its
good design, just giving a possible reason). It might also be possible
(though unlikely) that the flag is modified by the Set* function.
Dan

--
Remove devnull for email

[anony*mouse]

> It is not accepted in LCC-WIN32.

RETRACTION: Yes it is. Apologies to the defamed. My mistake.

I always thought that the 0 == NULL 'feature' was a product of C++ as
I commonly see C++ code that uses 0 in place of NULL(very ugly), while
I can't remember ever seeing this in C code.

[Dan Pop]

In <b6**************************@posting.google.com > an*********@subdimension.com (anony*mouse) writes:

I always thought that the 0 == NULL 'feature' was a product of C++ as
I commonly see C++ code that uses 0 in place of NULL(very ugly), while
I can't remember ever seeing this in C code.

0 as the null pointer constant originated in C. Because it was ugly, it
was hidden behind the NULL macro. C++ inherited it from C. Then, the
C89 standard introduced a second null pointer constant to C, (void *)0.
This one was never adopted by C++.

Well written C code always uses NULL, because it expresses the
programmer's intentions better than any explicit null pointer constant.
After all, this is why this macro was introduced in the first place.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Arthur J. O'Dwyer]

On Thu, 4 Mar 2004, Dan Pop wrote:

an*********@subdimension.com (anony*mouse) writes:

I always thought that the 0 == NULL 'feature' was a product of C++ as
I commonly see C++ code that uses 0 in place of NULL(very ugly), while
I can't remember ever seeing this in C code.
0 as the null pointer constant originated in C. Because it was ugly, it
was hidden behind the NULL macro. C++ inherited it from C. Then, the
C89 standard introduced a second null pointer constant to C, (void *)0.

I know that what you said is literally true, and the Standard
supports (void*)0 as a "second" null pointer constant, but really
it's just a corollary of the fact that 0 is a null pointer constant.
In C, (void*) can be implicitly converted to any other pointer type,
so (void*)0 and 0 are exactly interchangeable in pointer contexts.
This one was never adopted by C++.

In C++, (void*) cannot be implicitly converted to any other type,
so (void*)0 and 0 are not interchangeable in pointer contexts.

There's no magic going on with (void*)0's being a null pointer
constant; it's just a consequence of the C type system. And it's
not like C++ "decided" not to make (void*)0 equivalent to NULL;
that's just a consequence of the C++ type system.

-Arthur

[Jeremy Yallop]

Arthur J. O'Dwyer wrote:

In C++, (void*) cannot be implicitly converted to any other type,
so (void*)0 and 0 are not interchangeable in pointer contexts.
The first part is true, but that in itself is not a sufficient reason
for dropping (void *)0 as a null pointer constant in C++. Pointer to
void is not implicitly convertible to function pointer types in C, but

void (*f)() = (void *)0;

is valid C code.
There's no magic going on with (void*)0's being a null pointer
constant; it's just a consequence of the C type system.

For the most part that's true, but function pointers are a special
case.

Jeremy.

[Arthur J. O'Dwyer]

On Thu, 4 Mar 2004, Jeremy Yallop wrote:

Arthur J. O'Dwyer wrote:

In C++, (void*) cannot be implicitly converted to any other type,
so (void*)0 and 0 are not interchangeable in pointer contexts.
The first part is true, but that in itself is not a sufficient reason
for dropping (void *)0 as a null pointer constant in C++.

void (*f)() = (void *)0;

Oops! Thanks; I'll try to remember that in future. (Gee, that's
a weird aspect of C... ;-)

-Arthur

[Dan Pop]

In <Pi***********************************@unix44.andr ew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Thu, 4 Mar 2004, Dan Pop wrote:

an*********@subdimension.com (anony*mouse) writes:

>I always thought that the 0 == NULL 'feature' was a product of C++ as
>I commonly see C++ code that uses 0 in place of NULL(very ugly), while
>I can't remember ever seeing this in C code.
0 as the null pointer constant originated in C. Because it was ugly, it
was hidden behind the NULL macro. C++ inherited it from C. Then, the
C89 standard introduced a second null pointer constant to C, (void *)0.

I know that what you said is literally true, and the Standard
supports (void*)0 as a "second" null pointer constant, but really
it's just a corollary of the fact that 0 is a null pointer constant.

Nope, it isn't.
In C, (void*) can be implicitly converted to any other pointer type,
so (void*)0 and 0 are exactly interchangeable in pointer contexts.

Nope, they aren't: the result of converting an integer to a pointer is
*implementation-defined*, so, a priori, (void*)0 can be *anything*. Its
special semantics come *exclusively* from its *explicit* inclusion in the
definition of the null pointer constant.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Kenneth Brody]

Dan Pop wrote:
[...]

Well written C code always uses NULL, because it expresses the
programmer's intentions better than any explicit null pointer constant.
After all, this is why this macro was introduced in the first place.

Am I correct that all-bits-zero is not necessarily the same as NULL?

In other words, this is not guaranteed to get a set of 10 NULL pointers
(assuming the calloc succeeds):

char **pointers = calloc(10,sizeof(*pointers));

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[Kenneth Brody]

"Arthur J. O'Dwyer" wrote:
[...]

I know that what you said is literally true, and the Standard
supports (void*)0 as a "second" null pointer constant, but really
it's just a corollary of the fact that 0 is a null pointer constant.
In C, (void*) can be implicitly converted to any other pointer type,
so (void*)0 and 0 are exactly interchangeable in pointer contexts.

But, it prevents NULL from being passed in a non-pointer context.
I recently saw a post here (or c.l.c.m) using NULL instead of '\0'.
If NULL is defined as "0", this wouldn't cause a complaint, but if
it's defined "((void *)0)", it should flag a warning for you, which
(IMHO) is probably better.

[...]

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[Clark Cox]

In article <40***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:

Dan Pop wrote:
[...]

Well written C code always uses NULL, because it expresses the
programmer's intentions better than any explicit null pointer constant.
After all, this is why this macro was introduced in the first place.

Am I correct that all-bits-zero is not necessarily the same as NULL?

Yes.

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:
[...]

Am I correct that all-bits-zero is not necessarily the same as NULL?

In other words, this is not guaranteed to get a set of 10 NULL pointers
(assuming the calloc succeeds):

char **pointers = calloc(10,sizeof(*pointers));

Yes. See the C FAQ, <http://www.eskimo.com/~scs/C-faq/top.html>,
section 5.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[CBFalconer]

Kenneth Brody wrote:

Dan Pop wrote:
[...]

Well written C code always uses NULL, because it expresses the
programmer's intentions better than any explicit null pointer
constant. After all, this is why this macro was introduced in
the first place.

Am I correct that all-bits-zero is not necessarily the same as
NULL?

In other words, this is not guaranteed to get a set of 10 NULL
pointers (assuming the calloc succeeds):

char **pointers = calloc(10,sizeof(*pointers));

Definitely not guaranteed. You need something like:

int i;
char* *pointers;

if (!(pointers = malloc(10 * sizeof *pointers))) {
/* handle malloc failure */
}
else {
for (i = 0; i < 10; i++) pointer[i] = NULL;
}

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Mike Wahler]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:c2**********@sunnews.cern.ch...

In <GQ*****************@nwrddc02.gnilink.net> nrk <ra*********@devnull.verizon.net> writes:

This is quite normal with many such system calls that take flags (for
instance, open, creat, fcntl etc.).

Except that these functions don't take pointers to flags, they just take
the flags. I have yet to figure a good reason for requiring a pointer
to flags, unless the function is supposed to modify the user specified
flags (which would be really weird, as an API design).

Actually, some Windows API functions do exactly that.
Weird? You be the judge. :-)

-Mike

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <Pi***********************************@unix44.andr ew.cmu.edu>
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Thu, 4 Mar 2004, Dan Pop wrote:

an*********@subdimension.com (anony*mouse) writes:
>I always thought that the 0 == NULL 'feature' was a product of C++ as
>I commonly see C++ code that uses 0 in place of NULL(very ugly), while
>I can't remember ever seeing this in C code.

0 as the null pointer constant originated in C. Because it was ugly, it
was hidden behind the NULL macro. C++ inherited it from C. Then, the
C89 standard introduced a second null pointer constant to C, (void *)0.

I know that what you said is literally true, and the Standard
supports (void*)0 as a "second" null pointer constant, but really
it's just a corollary of the fact that 0 is a null pointer constant.

Nope, it isn't.

In C, (void*) can be implicitly converted to any other pointer type,
so (void*)0 and 0 are exactly interchangeable in pointer contexts.

Nope, they aren't: the result of converting an integer to a pointer is
*implementation-defined*, so, a priori, (void*)0 can be *anything*. Its
special semantics come *exclusively* from its *explicit* inclusion in the
definition of the null pointer constant.

The fact that (void*)0 is a "null pointer constant" does come
exclusively from its explicit inclusion in the definition. But even
if the definition of "null pointer constant" didn't mention void*, the
result of evaluating the expression (void*)0 would still be a null
pointer. (On the other hand, the result of evaluating (void*)x, where
x is an integer variable with the value 0, isn't necessarily a null
pointer.)

It's also important to keep in mind that a "null pointer constant" is
a construct in a source program, and a "null pointer" (which can be
obtained by evaluating a null pointer constant or by a number of other
means) is a value that exists at run time.

Here's the relevant paragraph, C99 6.3.2.3 p3 (using underscores to
denote italics):

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a _null pointer
constant_. If a null pointer constant is converted to a pointer
type, the resulting pointer, called a _null pointer_, is
guaranteed to compare unequal to a pointer to any object or
function.

and p4:

Conversion of a null pointer to another pointer type yields a null
pointer of that type. Any two null pointers shall compare equal.

So given
int zero = 0;

we have:

0 /* a null pointer constant */
(void*)0 /* a null pointer constant */
(int*)0 /* not a null pointer constant, but evaluates
to a null pointer value */
(void*)zero /* not a null pointer constant, may or may not
evaluate to a null pointer value */

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"