asd@cbnewsj.att.com (Adam S. Denton) (03/20/91)
Let's say I have a "generic" function that might work on different data types.
This function might look like this:
void generic_func(void *objectp, size_t size);
The intended call would be like this:
T *x; /* T is some type */
...
generic_func( (void *)x, sizeof(T) ); /* cast included for clarity */
...
Now, suppose generic_func() can be called with a nil pointer; i.e.,
x can be NULL (make that (T *)0).
For this to be useful, generic_func would have some code such as
...
/* Note, the following comparison compares "void *"s, not "T *"s!!! */
if (objectp == NULL) {...};
...
When generic_func is called, the nil (T *) argument x will be converted
to (void *) before generic_func gets it. My question is, is this
guaranteed to produce a *nil* generic pointer, or not? In other words,
does ANSI guarantee that (void *)0 compares equal to (void *)(T *)0,
or is this just wishful thinking on my part?
On a related note, can anything be said for (T1 *)0 vs. (T1 *)(T2 *)0?
(Not that converting arbitrary pointers is an acceptable practice... :-))
Thanks in advance,
Adam Denton
asd@mtqua.att.combhoughto@hopi.intel.com (Blair P. Houghton) (03/20/91)
People have been asking ANSI-questions like they're writing a test suite for the standard... In article <1991Mar19.234219.22867@cbnewsj.att.com> asd@cbnewsj.att.com (Adam S. Denton) writes: [...for some defined types T, T1, and T2...] >does ANSI guarantee that (void *)0 compares equal to (void *)(T *)0, >or is this just wishful thinking on my part? >On a related note, can anything be said for (T1 *)0 vs. (T1 *)(T2 *)0? >(Not that converting arbitrary pointers is an acceptable practice... :-)) "Two null pointers, converted through possibly different sequences of casts to pointer types, shall compare equal." (ANSI X3.159-1989, sec. 3.2.2.3, p. 38, ll. 5-6) --Blair "Works for me."
henry@zoo.toronto.edu (Henry Spencer) (03/21/91)
In article <1991Mar19.234219.22867@cbnewsj.att.com> asd@cbnewsj.att.com (Adam S. Denton) writes: >When generic_func is called, the nil (T *) argument x will be converted >to (void *) before generic_func gets it. My question is, is this >guaranteed to produce a *nil* generic pointer, or not? In other words, >does ANSI guarantee that (void *)0 compares equal to (void *)(T *)0... (Point of terminology: there is no such thing as "nil" in C. You are talking about null pointers.) ANSI C guarantees that a null pointer of one type, converted to another type, is a null pointer of the new type. -- "[Some people] positively *wish* to | Henry Spencer @ U of Toronto Zoology believe ill of the modern world."-R.Peto| henry@zoo.toronto.edu utzoo!henry
gordon@osiris.cso.uiuc.edu (John Gordon) (03/21/91)
On a mostly unrelated note, C++ overcomes this problem quite neatly. You can define multiple functions of the same name that take different types, and the compiler will know what function to execute based on what type you pass it.
torek@elf.ee.lbl.gov (Chris Torek) (03/21/91)
In article <1991Mar20.174710.4405@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >(Point of terminology: there is no such thing as "nil" in C. You are >talking about null pointers.) True---but I sometimes advocate using `nil pointer' as a circumloction for `null pointer of type T', simply because the very absence of the `nil' keyword guarantees that you have to change *something*, whereas if you say `a null pointer' it is not at all clear that you might have to code something other than just `NULL'. But alas, the new BSD man pages are going to continue to talk blithely about `NULL' as if the compiler worked magic. Fortunately, in this case all the new man pages will say #include <foo.h> and <foo.h> will contain all the necessary prototypes, so if you follow the man page, you will have a prototype in scope, and the compiler *will* work magic.... -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov