NULL as a null function pointer
Ben Pfaff
and C99 both seem to say that this is okay, but Plauger says it
is not and the C89 and C99 rationales imply that it is not. It
seems odd that such respected sources would disagree.
Equivalents to all of the references below exist in C89 or the
C89 Rationale.
C99 6.3.2.3#3 defines a null pointer constant and implies that
any null pointer constant, including (void *) 0, can be converted
to a function pointer:
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer
constant.55) 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.
C99 6.5.9#5 on the equality operators says that any pointer, not
just a function pointer, may be compared to a null pointer
constant:
Otherwise, at least one operand is a pointer. If one operand
is a pointer and the other is a null pointer constant, the
null pointer constant is converted to the type of the
pointer.
C99 6.5.15 on the conditional operator seems to give the same
latitude, and 6.5.16.1 does not restrict assignment of null
pointer constants to object pointers only. 6.6 says that any
kind of null pointer constant is a valid in an initializer.
6.7.8 on initializers doesn't put in arbitrary restrictions,
either.
Given this, I don't understand why the C99 Rationale (and C89
Rationale in a corresponding section) implies in 6.5.14 that NULL
may only be compared to an object pointer:
In pointer comparisons, one of the operands may be of type
void*. In particular, this allows NULL, which can be defined
as (void*)0, to be compared to any object pointer.
^^^^^^
Moreover, it gives the following rather puzzling comment in 7.17:
It has never been wise to use NULL in place of an arbitrary
pointer as a function argument, however, since pointers to
different types need not be the same size. The library
avoids this problem by providing special macros for the
arguments to signal, the one library function that might see
a null function pointer.
This is puzzling because it would only be a problem to use a null
pointer constant as a function argument if the function was not
prototyped. But including the library header to get the special
macro that they provide as a "solution" will give a prototype, so
there is no real advantage.
Plauger says explicitly that NULL is not a valid null function
pointer constant on page 220 of _The Standard C Library_:
...As I mentioned on page 216, the macro can have any of the
definitions 0, 0L, or (void *) 0.
The last definition is compatible with any data object
pointer. It is /not/, however, compatible with a function
pointer. That means you cannot write:
int (*pfun)(void) = NULL; /* WRONG! */
So, what's up? Either I am misinterpreting the C89 and C99
Standards, or both the C89 and C99 Rationales and a committee
member are wrong. (In the latter case, does anyone know of a
list of errata for _The Standard C Library_?)
--
"Ho ho ho. I _so_ enjoy making a fool out of myself."
--Linus, on Christmas Day, 2000
Richard Heathfield
>
> I am confused. May NULL be used as a null function pointer? C89
> and C99 both seem to say that this is okay, but Plauger says it
> is not and the C89 and C99 rationales imply that it is not. It
> seems odd that such respected sources would disagree.
I'm not sure whether P J Plauger and the Rationales are normative, but
the Standard certainly is.
Anyway, it's an FAQ. Not sure if 5.8 is in the online version of the
FAQ, so I'll just note here that it says an unequivocal yes (but also
refers you to question 4.13, which is intended to discourage you from
trying to convert functinos to void * and back).
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Lawrence Kirby
b...@cs.stanford.edu "Ben Pfaff" writes:
(I've added comp.std.c to the newshroups list)
>I am confused. May NULL be used as a null function pointer?
It may be converted implicitly to a null pointer of pointer to
function type.
> C89
>and C99 both seem to say that this is okay, but Plauger says it
>is not and the C89 and C99 rationales imply that it is not. It
>seems odd that such respected sources would disagree.
Odd indeed!
...
>C99 6.5.9#5 on the equality operators says that any pointer, not
>just a function pointer, may be compared to a null pointer
>constant:
>
> Otherwise, at least one operand is a pointer. If one operand
> is a pointer and the other is a null pointer constant, the
> null pointer constant is converted to the type of the
> pointer.
...
>C99 6.5.15 on the conditional operator seems to give the same
>latitude, and 6.5.16.1 does not restrict assignment of null
>pointer constants to object pointers only.
I.e. my statement at the top is correct, along with your own view.
Most implicit conversions relevant to pointers are done
"as if by assignment" so 6.5.16.1 is the most significant reference.
"- The left operand is a pointer and the right is a null pointer constant"
...
>Given this, I don't understand why the C99 Rationale (and C89
>Rationale in a corresponding section) implies in 6.5.14 that NULL
>may only be compared to an object pointer:
>
> In pointer comparisons, one of the operands may be of type
> void*. In particular, this allows NULL, which can be defined
> as (void*)0, to be compared to any object pointer.
> ^^^^^^
I guess that doesn't rule out comparisons to function pointers but it
is misleading. In general void * pointers can't be compared directly
against or converted to function pointers but null pointer constants
including those that have type void * can.
>Moreover, it gives the following rather puzzling comment in 7.17:
>
> It has never been wise to use NULL in place of an arbitrary
> pointer as a function argument, however, since pointers to
> different types need not be the same size. The library
> avoids this problem by providing special macros for the
> arguments to signal, the one library function that might see
> a null function pointer.
>
>This is puzzling because it would only be a problem to use a null
>pointer constant as a function argument if the function was not
>prototyped. But including the library header to get the special
For example
printf("%p", NULL);
is unsafe. Still, passing NULL to prototyped functions is fine where it
is not an argument in the ... part of a variable argument list, assuming
that a null pointer is a valid argument value for that function.
>macro that they provide as a "solution" will give a prototype, so
>there is no real advantage.
>
>Plauger says explicitly that NULL is not a valid null function
>pointer constant on page 220 of _The Standard C Library_:
>
> ...As I mentioned on page 216, the macro can have any of the
> definitions 0, 0L, or (void *) 0.
>
> The last definition is compatible with any data object
> pointer. It is /not/, however, compatible with a function
> pointer. That means you cannot write:
>
> int (*pfun)(void) = NULL; /* WRONG! */
>
>So, what's up? Either I am misinterpreting the C89 and C99
>Standards, or both the C89 and C99 Rationales and a committee
>member are wrong. (In the latter case, does anyone know of a
>list of errata for _The Standard C Library_?)
Congratulations, you appear to have found a genuine error in Plauger. Such
beasts are rare. :-)
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Dan Pop
>Ben Pfaff wrote:
>>
>> I am confused. May NULL be used as a null function pointer? C89
>> and C99 both seem to say that this is okay, but Plauger says it
>> is not and the C89 and C99 rationales imply that it is not. It
>> seems odd that such respected sources would disagree.
>
>I'm not sure whether P J Plauger and the Rationales are normative, but
>the Standard certainly is.
>
>Anyway, it's an FAQ.
That's misleading:
1. This question is not frequently asked in this newsgroup.
2. The official c.l.c FAQ (i.e. the one posted in this newsgroup, by its
maintainer) doesn't answer it.
>Not sure if 5.8 is in the online version of the FAQ,
It isn't.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland