dereferencing function pointer types

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

vippstar@gmail.com wrote: > 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. 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. An expression of function type is converted to an expression of pointer type, in all but two contexts: 1 & (function type expression) 2 sizeof(function type expression) Since sizeof is not defined for expressions of function type, the only thing that you can do with an expression of function type in a correct C program, is to derive a pointer from it. A function call is described a pointer to a function type expression followed by the function call operator, which is the parentheses in a function call. So, if func is the name of a function in a function call, it is converted to a pointer. func(); does the same thing as (&func)(); In (*func)(); the name of the function is converted to a pointer implicitly; the indirection operator yields an expression of function type and that expression is converted to a pointer. So, (*********************************func)(); also does the same thing as func(); But with (&func)(); you have the result of the address operator from a function type operand. That's a function pointer, and if you apply & to that, you get the address of the result of the address operator and that means nothing. -- pete

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=A9=A6k <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 <cbfalconer@yahoo.com> 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-u@mib.org <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"

vippstar@gmail.com wrote: > (&&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. This one has something to do with it: (&(&f))(0) See what your compiler says. -- pete

Keith Thompson wrote: > CBFalconer <cbfalconer@yahoo.com> 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.

Keith Thompson said: <snip> > (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.) The trolls are themselves regulars, and they criticise other regulars all the time, if the replies I see are anything to go by. But comp.lang.c isn't about constructing a nice little community - it's about discussing C. When people get the C wrong, they should expect to be corrected. When they get it wrong a lot, they should expect to be criticised. When they get it wrong practically all the time, it is likely that such criticism will be particularly heavy, sometimes taking shape as mockery or scorn. If people want to avoid criticism, the answer is not "become one of the 'clique'" because the 'clique' in comp.lang.c is a myth. Rather, the answer is "get your C right". A 'clique' is an inner circle to which admittance is restricted by arbitrary and perhaps unwritten rules. If comp.lang.c has an inner circle, it is composed of *all* those people who know the C language, i.e. C experts - which means that clc's 'inner circle' has people in it who have never posted so much as a single article. They may never even have heard of clc. You don't need to be a regular clc contributor to be a C expert, but you do need to be a C expert if you want comp.lang.c to treat you as one. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ Google users: <http://www.cpax.org.uk/prg/writings/googly.php> "Usenet is a strange place" - dmr 29 July 1999

In article <lzr6adt2fk.fsf@stalkings.ghoti.net>, Keith Thompson <kst-u@mib.org> 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 <lzr6adt2fk.fsf@stalkings.ghoti.net>, > Keith Thompson <kst-u@mib.org> 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...