dereferencing function pointer types

[viza]

Hi

I have program1.c:

typedef int (*fn_t)(int);

int fn( int f ){
return f;
}

int main( void ){

fn_t f= fn;

return f( 0 );
}

and program2.c

typedef int (*fn_t)(int);

int fn( int f ){
return f;
}

int main( void ){

fn_t f= fn;

return (*f)( 0 );
}

They both compile with no errors/warnings/comments under
gcc -Wall -ansi -pedantic

and in fact produce identical executables.

What is the story with function pointers? Is it good style to
dereference them to call them? Gcc doesn't even complain about return
(**f)(0); !

I would have guessed that since I can write f= fn; that f and fn have the
same type, but then Gcc doesn't complain about f= & fn; either, which
makes more sense when you look at the typedef.

So should I write f= fn or f= &fn, and should I write f(0); or (*f)(0);

The former in each case is what you would do if functions were like an
array type, and the latter makes sense if pointers were like scalars.

Surely the standard can't permit both - that seems quite sloppy.

Thanks,
viza

 

[vippstar]

Hi

I have program1.c:

typedef int (*fn_t)(int);

int fn( int f ){
return f;

}

int main( void ){

fn_t f= fn;

return f( 0 );

}

and program2.c

typedef int (*fn_t)(int);

int fn( int f ){
return f;

}

int main( void ){

fn_t f= fn;

return (*f)( 0 );

}

They both compile with no errors/warnings/comments under
gcc -Wall -ansi -pedantic

and in fact produce identical executables.

What is the story with function pointers? Is it good style to
dereference them to call them? Gcc doesn't even complain about return
(**f)(0); !

Dereferencing a function pointer does nothing.

I would have guessed that since I can write f= fn; that f and fn have the
same type, but then Gcc doesn't complain about f= & fn; either, which
makes more sense when you look at the typedef.

So should I write f= fn or f= &fn, and should I write f(0); or (*f)(0);

I prefer f = fn. As for the latter, some programmers/projects prefer
to have (*f)(0) to make clear 'f' is a function pointer; I prefer f(0)
though.

The former in each case is what you would do if functions were like an
array type, and the latter makes sense if pointers were like scalars.

Function pointers are scalars. But the effect of * and & does not
apply to them.

Surely the standard can't permit both - that seems quite sloppy.

It does

 

[vippstar]

That's very close to being correct.
But if it were correct,
then (&&f)(0) would mean the same thing as (&f)(0),
and it doesn't.
(&&f)(0) is undefined.

No, I'm correct. (&&f)(0) is a syntax error. && is the logical
operator, it has nothing to do with my claim that the effect of '&'
does not apply to function pointers.

 

[Harald van Dijk]

No, I'm correct. (&&f)(0) is a syntax error. && is the logical operator,
it has nothing to do with my claim that the effect of '&' does not apply
to function pointers.

pete surely meant (& &f)(0). He is correct that this is not allowed in C,
because &f does have an effect: it takes the address of function f, and
gives an rvalue[1] expression of type pointer-to-function. You cannot
apply the operator twice, because you cannot apply the unary & operator to
_any_ rvalue.

[1] value of object type that is not an lvalue

 

[vippstar]

No, I'm correct. (&&f)(0) is a syntax error. && is the logical operator,
it has nothing to do with my claim that the effect of '&' does not apply
to function pointers.

pete surely meant (& &f)(0). He is correct that this is not allowed in C,
because &f does have an effect: it takes the address of function f, and
gives an rvalue[1] expression of type pointer-to-function. You cannot
apply the operator twice, because you cannot apply the unary & operator to
_any_ rvalue.

[1] value of object type that is not an lvalue

ah I see. Yes, I do agree with this.

 

[CBFalconer]

.... snip ...


No, I'm correct. (&&f)(0) is a syntax error. && is the logical
operator, it has nothing to do with my claim that the effect of
'&' does not apply to function pointers.

pete surely meant (& &f)(0). He is correct that this is not
allowed in C, because &f does have an effect: it takes the
address of function f, and gives an rvalue[1] expression of type
pointer-to-function. You cannot apply the operator twice, because
you cannot apply the unary & operator to _any_ rvalue.

[1] value of object type that is not an lvalue

No, functions are peculiar things. If f(whatever) is a function,
the expression f means the address of the code of that function.
The expression &f says take the address, and means the same thing.
Similarly &&f, and &&&&&&&f.

 

[Keith Thompson]

No, functions are peculiar things. If f(whatever) is a function,
the expression f means the address of the code of that function.
The expression &f says take the address, and means the same thing.

So far, so good.

Similarly &&f, and &&&&&&&f.

You are mistaken on at least two counts.

First of all, &&f is tokenized as "&&" "f", so &&f is a syntax error.
vippstar mentioned this in text that you quoted (but apparently
neglected to read).

Second, &f is an expression of pointer-to-function type, but it's not
an lvalue, so & &f violates a constraint.

It's true that the following are all equivalent:
&f
f
*f
**f
***f
****f
etc.
because (a) "**" isn't a single token, and (b) the unary "*" operator
doesn't require an lvalue as its operand.

(I'm sure the trolls are chortling in their caves about one of the
"regulars" criticizing another. They are welcome, as always, to ...
never mind, this is a family newsgroup.)

 

[CBFalconer]

So far, so good.


You are mistaken on at least two counts.

First of all, &&f is tokenized as "&&" "f", so &&f is a syntax
error. vippstar mentioned this in text that you quoted (but
apparently neglected to read).

Second, &f is an expression of pointer-to-function type, but it's
not an lvalue, so & &f violates a constraint.

It's true that the following are all equivalent:
&f
f
*f
**f
***f
****f
etc.
because (a) "**" isn't a single token, and (b) the unary "*"
operator doesn't require an lvalue as its operand.

(I'm sure the trolls are chortling in their caves about one of
the "regulars" criticizing another. They are welcome, as always,
to ... never mind, this is a family newsgroup.)

Ahh yes - you are right. I was thinking that the use of && for
logic required a phrase of the form <object && object> to be so
parsed. Thanks for the correction.

 

[Kenny McCormack]

(I'm sure the trolls are chortling in their caves about one of the
"regulars" criticizing another. They are welcome, as always, to ...
never mind, this is a family newsgroup.)

Would we do *that*? Au contraire...

What? Oh, OK. Yes, let me be the first to call it:

Chick fight!

 

[Antoninus Twink]

Would we do *that*? Au contraire...

In this instance, we have a regular criticizing CBF. That's such a
depressingly routine occurrence by now that it's more likely to provoke
boredom than laughter. When you can be such a stubbornly wrong dickhead
that Harold van Dijk loses patience with you, it's really the end of the
road.

CBFalconer - 82 years old, and fingers crossed, any day now...