«

I have a function that has a function pointer as one of its argument.
Can I pass NULL as this parameter?

I have some code (from lwip project - www.sics.se/~adam/lwip) that
often pass NULL as function pointer parameter, but my compiler (for 16
bits Fujtsu 16LX series microcontrollers) gives a warning for that.
For example:
argument passing incompatible pointer types:
expected `tcp_accept_fn' actual `void *': argument 2 of
`tcp_accept'

On Thu, 17 Feb 2011, pozz wrote:

> I have a function that has a function pointer as one of its argument.
> Can I pass NULL as this parameter?
> [...]

Hmm... well, dereferencing a null pointer is undefined behavior.
So, probably not. Of coarse, OTOH I'm fairly new here.

On 02/17/2011 08:50 AM, Douglas wrote:
> On Thu, 17 Feb 2011, pozz wrote:
>
>> I have a function that has a function pointer as one of its argument.
>> Can I pass NULL as this parameter?
>> [...]
>
> Hmm... well, dereferencing a null pointer is undefined behavior.
> So, probably not. Of coarse, OTOH I'm fairly new here.

He didn't say that the pointer would be de-referenced. When part of a
function's behavior is optional in a way that is connected to one of
it's pointer parameters, it's fairly commonplace to use a null pointer
argument of that type to indicate that the optional behavior should be
skipped.

--
James Kuyper

pozz wrote:

> ... my compiler (for 16 bits Fujtsu 16LX series microcontrollers) gives a warning for that.
> For example:
> argument passing incompatible pointer types:
> expected `tcp_accept_fn' actual `void *': argument 2 of
>`tcp_accept'

In addition to what others wrote, that warning complains about
incompatible types, not about the pointer being NULL.
If you want a "clean compile", casting NULL into the type of function
pointer expected will squelch the warning.

--
Roberto Waltman

[ Please reply to the group.
Return address is invalid ]

Roberto Waltman <> writes:
> pozz wrote:
>> ... my compiler (for 16 bits Fujtsu 16LX series microcontrollers) gives a warning for that.
>> For example:
>> argument passing incompatible pointer types:
>> expected `tcp_accept_fn' actual `void *': argument 2 of
>>`tcp_accept'
>
> In addition to what others wrote, that warning complains about
> incompatible types, not about the pointer being NULL.
> If you want a "clean compile", casting NULL into the type of function
> pointer expected will squelch the warning.

Yes, that will likely silence the warning -- but keep in mind
that it's a workaround for a compiler bug. (I don't mean
a "bug" in the sense that the compiler is necessarily non-conforming,
just that the warning is spurious.)

You do generally need to cast NULL to the expected pointer type when
calling variadic functions, but that's not what's happening here; the
compiler wouldn't know the expected type.

A couple of questions for the OP:

Does the compiler you're using claim to be conforming? If not, what
does its documentation say about the use of function pointers?

Since you didn't show us the full source of the program, we can't be
100% sure of what's going on. What happens when you compile this?

typedef void (*funcptr)(void);

void func(funcptr arg)
{
if (arg) {
arg();
}
}

int main(void)
{
func((void*)0);
return 0;
}

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Feb 17, 3:18*am, pozz <pozzu...@libero.it> wrote:
> I have a function that has a function pointer as one of its argument.
> Can I pass NULL as this parameter?
>
> I have some code (from lwip project -www.sics.se/~adam/lwip) that
> often pass NULL as function pointer parameter, but my compiler (for 16
> bits Fujtsu 16LX series microcontrollers) gives a warning for that.
> For example:
> * argument passing incompatible pointer types:
> * * expected `tcp_accept_fn' actual `void *': argument 2 of
> `tcp_accept'

Of course, if a few CPU cycles won't kill you, it's always better to
pass a pointer to properly shaped function that does nothing.

Michael Angelo Ravera <> writes:
> On Feb 17, 3:18Â*am, pozz <pozzu...@libero.it> wrote:
>> I have a function that has a function pointer as one of its argument.
>> Can I pass NULL as this parameter?
>>
>> I have some code (from lwip project -www.sics.se/~adam/lwip) that
>> often pass NULL as function pointer parameter, but my compiler (for 16
>> bits Fujtsu 16LX series microcontrollers) gives a warning for that.
>> For example:
>> Â* argument passing incompatible pointer types:
>> Â* Â* expected `tcp_accept_fn' actual `void *': argument 2 of
>> `tcp_accept'
>
> Of course, if a few CPU cycles won't kill you, it's always better to
> pass a pointer to properly shaped function that does nothing.

Why is that always better? If the function is specified to do nothing
if the passed function pointer is null, what's wrong with passing a null
pointer (assuming the compiler doesn't issue a spurious diagnostic)?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 17 Feb, 17:39, Keith Thompson <ks...@mib.org> wrote:
> Yes, that will likely silence the warning -- but keep in mind
> that it's a workaround for a compiler bug. *(I don't mean
> a "bug" in the sense that the compiler is necessarily non-conforming,
> just that the warning is spurious.)

Yes, I think I'll use this workaround, just to silence this warning.


> Does the compiler you're using claim to be conforming? *If not, what
> does its documentation say about the use of function pointers?

Nothing special.


> Since you didn't show us the full source of the program, we can't be
> 100% sure of what's going on. *What happens when you compile this?
> [...]

The warning comes again out...

"pozz" <> wrote:
On 17 Feb, 17:39, Keith Thompson <ks...@mib.org> wrote:
> > Since you didn't show us the full source of the program, we can't be
> > 100% sure of what's going on. What happens when you compile this?
> > [...]
>
> The warning comes again out...

That seems to be non-standard behavior.

What happens if you compile Keith’s example program, but with the line
func((void*)0);
replaced with
func(0);
— does that work better?

According to the standard (§6.3.2.3 p3), the following holds:

int main(void)
{
func(0); // should work
func((void*)0); // should also work, but your system is non-standard
func(NULL); // resolves to either of the foregoing; should work
void *null = 0;
func(null); // should *not* work
func((funcptr)null); // often permitted (common extension §J.5.7),
// but not portable, nor guaranteed to work as
// expected even if it compiles
return 0;
}

Both “0� and “(void*)0� are “null pointer constants� and *should* convert to
null pointers or null function pointers as required. You might need to override
your system’s definition of NULL from “(void*)0� to “0� to compensate for its
non-standard behavior. Probably a better idea than introducing casts all over.

—Joel

"Joel C. Salomon" <> writes:
> "pozz" <> wrote:
> On 17 Feb, 17:39, Keith Thompson <ks...@mib.org> wrote:
>> > Since you didn't show us the full source of the program, we can't be
>> > 100% sure of what's going on. What happens when you compile this?
>> > [...]
>>
>> The warning comes again out...
>
> That seems to be non-standard behavior.

It doesn't *violate* the standard. Compilers can issue any additional
warnings they like. They just have to generate correctly working code
for programs that don't violate any syntax rules or constraints, issue
diagnostics for any violations of any syntax rules or constraints, and
refuse to compile anything with an active #error directive.

The warning about a valid construct does make me worry a little about
whether the compiler is generating correct code for it, though.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"