«

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

On Jul 1, 9:11 pm, viza <tom.v...@gmil.com> wrote:
> 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

On Jul 1, 11:28 pm, pete <pfil...@mindspring.com> wrote:
> vipps...@gmail.com wrote:
> > On Jul 1, 9:11 pm, viza <tom.v...@gmil.com> wrote:
> >> 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.
>
> 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.

On Tue, 01 Jul 2008 15:37:43 -0700, vippstar wrote:
> On Jul 1, 11:28 pm, pete <pfil...@mindspring.com> wrote:
>> vipps...@gmail.com wrote:
>> > On Jul 1, 9:11 pm, viza <tom.v...@gmil.com> wrote:
>> >> 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.
>>
>> 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.

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

On Jul 2, 1:56 am, Harald van D©¦k <true...@gmail.com> wrote:
> On Tue, 01 Jul 2008 15:37:43 -0700, vippstar wrote:
> > On Jul 1, 11:28 pm, pete <pfil...@mindspring.com> wrote:
> >> vipps...@gmail.com wrote:
> >> > On Jul 1, 9:11 pm, viza <tom.v...@gmil.com> wrote:
> >> >> 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.
>
> >> 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.
>
> 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.

Harald van D?k wrote:
> vippstar wrote:
>> pete <pfil...@mindspring.com> wrote:
>>
.... snip ...
>>
>>> 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.
>
> 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

CBFalconer <> writes:
[...]
> 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.)

--
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"

Keith Thompson wrote:
> CBFalconer <> writes:
> [...]
>> 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.)

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

In article <>,
Keith Thompson <kst-> wrote:
....
>(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!

On 2 Jul 2008 at 10:41, Kenny McCormack wrote:
> In article <>,
> Keith Thompson <kst-> wrote:
> ...
>>(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...

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...