By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,111 Members | 1,665 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,111 IT Pros & Developers. It's quick & easy.

Question about C Functions

P: n/a
If I have the function:

int f(int (*h)(int)) {
return (*h)(13);
}

What exactly does (int (*h)(int)) do? So it's taking a pointer but
what's with the two ints? Thanks.

Nov 1 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
jobo wrote:
If I have the function:

int f(int (*h)(int)) {
return (*h)(13);
}

What exactly does (int (*h)(int)) do? So it's taking a pointer but
what's with the two ints? Thanks.
f is a function returning int. It takes as an argument a pointer
to a function returning int, which function takes an int as an
argument. f's argument is called h. f calls the function
pointed to by h with an argument of 13.

Look for the program called cdecl, which helps explain C
declarations.

--
Thomas M. Sommers -- tm*@nj.net -- AB2SB

Nov 1 '06 #2

P: n/a
jobo wrote:
If I have the function:

int f(int (*h)(int)) {
return (*h)(13);
}

What exactly does (int (*h)(int)) do? So it's taking a pointer but
what's with the two ints? Thanks.


Incrementally read as:

h -- a pointer
(*h) -- whose dereferenced value
(*h)(int) -- is a function that accepts a single int as a
parameter
int (*h)(int) -- and returns an int
Thus h is a pointer to a function with the aforementioned parameter
and return types. For example, h can be used to point to the 'toupper'
function defined in the C standard:
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main (void)
{
int (*h)(int);
h = toupper;
printf ("%c programming is hard!\n", (*h)('c'));
return 0;
}

--
Hope this helps,
Steven

Nov 1 '06 #3

P: n/a
"jobo" <jo*****@gmail.comwrites:
If I have the function:

int f(int (*h)(int)) {
return (*h)(13);
}

What exactly does (int (*h)(int)) do? So it's taking a pointer but
what's with the two ints? Thanks.
f is a function that returns a result of type int. It has a single
parameter, "h", of type int (*)(int). In other words, h is a pointer
to a function; that function has a single parameter of type int, and
returns a result of type int.

There's a program called "cdecl" that's often helpful for this kind of
thing (though it doesn't like the parameter name):

% cdecl
Type `help' or `?' for help
cdeclexplain int f(int (*h)(int))
syntax error
cdeclexplain int f(int (*)(int))
declare f as function (pointer to function (int) returning int) returning int
cdecl>

I got it from
<http://www.ibiblio.org/pub/Linux/devel/lang/c/cdecl-2.5.tar.gz>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 1 '06 #4

P: n/a
at*************@gmail.com wrote:
jobo wrote:
>What exactly does (int (*h)(int)) do? So it's taking a pointer but
what's with the two ints? Thanks.

Incrementally read as:

h -- a pointer
From 'h' all we can tell is that 'h' is an identifier.
(*h) -- whose dereferenced value
Only now can we see that 'h' is a pointer whose dereferenced value ...
(*h)(int) -- is a function that accepts a single int as a parameter
int (*h)(int) -- and returns an int
I would read it like this:

h -- object
*h -- pointer
(*h) -- pointer
int (*h)(int) -- pointer to function (int) returning int

--
Simon.
Nov 1 '06 #5

P: n/a
jobo:
int f(int (*h)(int)) {
return (*h)(13);
}

The parentheses and dereference are redundant.

int f(int (*const Func)(int))
{
return Func(13);
}

--

Frederick Gotham
Nov 1 '06 #6

P: n/a
Frederick Gotham wrote:
jobo:
>int f(int (*h)(int)) {
return (*h)(13);
}


The parentheses and dereference are redundant.

int f(int (*const Func)(int))
{
return Func(13);
}
For some reason cdecl chokes on your definition above. When I give it
just the parameter, it's fine:

cdeclexplain int (* const Func)(int)
declare Func as const pointer to function (int) returning int

But when I give it the whole thing (minus the name of the parameter), it
chokes:

cdeclexplain int f(int (*const)(int))
syntax error

On further exploration it seems to choke on all const pointers as
parameters:

cdeclexplain int f(int *const)
syntax error

However it works properly in the other direction:

cdecldeclare f as function (const pointer to function (int) returning
int) returning int
int f(int (* const )(int ))

--
Simon.
Nov 1 '06 #7

P: n/a
Simon Biber:
For some reason cdecl chokes on your definition above.

Sorry, I don't know what cdecl is.

<snip cdecl stuff>

At first glance, all the ones that give syntax errors are the ones which
cannot serve as standalone declarations, e.g.:

int main(void)
{
int (*const)(int);
}

--

Frederick Gotham
Nov 1 '06 #8

P: n/a
Frederick Gotham said:
Simon Biber:
>For some reason cdecl chokes on your definition above.


Sorry, I don't know what cdecl is.
Read K&R2 more closely.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 1 '06 #9

P: n/a
On Wed, 01 Nov 2006 15:43:46 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:
>Simon Biber:
>For some reason cdecl chokes on your definition above.


Sorry, I don't know what cdecl is.
This is obvious from one of your comments in a different thread.
cdecl is a programme that describes a C construct in human.

# cdecl explain int arr[2][2]
declare arr as array 2 of array 2 of int

I strongly recommend you obtain and play with it, its jolly useful not
to mention helping clarify some other questions.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Nov 1 '06 #10

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
[...]
cdecl is a programme that describes a C construct in human.

# cdecl explain int arr[2][2]
declare arr as array 2 of array 2 of int

I strongly recommend you obtain and play with it, its jolly useful not
to mention helping clarify some other questions.
One thing to watch out for is that it allows aliases for certain
things; see the documentation for details. I've run into this myself:

% cdecl
Type `help' or `?' for help
cdecldeclare ptr as pointer to int
syntax error
cdecldeclare p as pointer to int
int *p

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 1 '06 #11

P: n/a
Mark McIntyre:
This is obvious from one of your comments in a different thread.
cdecl is a programme that describes a C construct in human.

# cdecl explain int arr[2][2]
declare arr as array 2 of array 2 of int

I strongly recommend you obtain and play with it, its jolly useful not
to mention helping clarify some other questions.

You're offering armbands to a proficient swimmer.

--

Frederick Gotham
Nov 2 '06 #12

P: n/a
Frederick Gotham said:
Mark McIntyre:
>This is obvious from one of your comments in a different thread.
cdecl is a programme that describes a C construct in human.

# cdecl explain int arr[2][2]
declare arr as array 2 of array 2 of int

I strongly recommend you obtain and play with it, its jolly useful not
to mention helping clarify some other questions.

You're offering armbands to a proficient swimmer.
No, no, he was offering them to /you/.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 2 '06 #13

P: n/a
Richard Heathfield:
>You're offering armbands to a proficient swimmer.

No, no, he was offering them to /you/.

Is that a challenge? Throw a declaration at me so, one I can't make head nor
tails of.

--

Frederick Gotham
Nov 2 '06 #14

P: n/a
Frederick Gotham wrote:
Richard Heathfield:
>>You're offering armbands to a proficient swimmer.

No, no, he was offering them to /you/.

Is that a challenge? Throw a declaration at me so, one I can't make head nor
tails of.
Well, `throw` is of course off-topic here, but:

void yorkshire() { int stomach; }

seems to fit.

--
Chris "I had the guts for it" Dollin
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

Nov 2 '06 #15

P: n/a
Frederick Gotham said:
Richard Heathfield:
>>You're offering armbands to a proficient swimmer.

No, no, he was offering them to /you/.


Is that a challenge?
No. It was merely an observation, based on your apparent inability to grasp
the purposes of standardisation and civility.
Throw a declaration at me so, one I can't make head
nor tails of.
I declare that you owe several people in this newsgroup an apology.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 2 '06 #16

P: n/a
Richard Heathfield:
>Throw a declaration at me so, one I can't make head
nor tails of.

I declare that you owe several people in this newsgroup an apology.

In the absence of supplying of a declaration which I would not comprehend, I
accept your concession that I have no need for cdecl.

--

Frederick Gotham
Nov 2 '06 #17

P: n/a
Frederick Gotham said:
Richard Heathfield:
>>Throw a declaration at me so, one I can't make head
nor tails of.

I declare that you owe several people in this newsgroup an apology.


In the absence of supplying of a declaration which I would not comprehend,
I accept your concession that I have no need for cdecl.
It is clear from your reply that you cannot make head or tail of my
declaration, QED.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 2 '06 #18

P: n/a
Richard Heathfield wrote:
Frederick Gotham said:
.... snip ...
>
>Throw a declaration at me so, one I can't make head nor tails of.

I declare that you owe several people in this newsgroup an apology.
That definitely fits, as he has demonstrated his inability to
comprehend that multiple times.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Nov 2 '06 #19

P: n/a
Richard Heathfield <in*****@invalid.invalidwrote:
Frederick Gotham said:
(snip)
I declare that you owe several people in this newsgroup an apology.
Again, would it be possible to identify these posts which consist of
nothing more than seemingly hopeless attempts to induce some measure
of civility in Mr. Gotham? I've plonked Mr. Gotham expressly to avoid
as much involvement as possible in these discussions, but short of
either filtering entire threads (not so good) or filtering *your*
posts (very bad), there is little the rest of us can do to steer clear
of these recurring subthreads.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Nov 2 '06 #20

P: n/a
In article <ei**********@chessie.cirr.comChristopher Benson-Manica <at***@otaku.freeshell.orgwrites:
Richard Heathfield <in*****@invalid.invalidwrote:
Frederick Gotham said:
(snip)
I declare that you owe several people in this newsgroup an apology.

Again, would it be possible to identify these posts which consist of
nothing more than seemingly hopeless attempts to induce some measure
of civility in Mr. Gotham? I've plonked Mr. Gotham expressly to avoid
as much involvement as possible in these discussions, but short of
either filtering entire threads (not so good) or filtering *your*
posts (very bad), there is little the rest of us can do to steer clear
of these recurring subthreads.
If you have a newsreader that can filter based on content rather than
headers (I have), there is no problem. Not that I use a filter (although
this newsreader was the first that was able to filter, and the second
newsreader ever; that is progress for you).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 3 '06 #21

P: n/a
In article <pq*******************@news.indigo.ieFrederick Gotham <fg*******@SPAM.comwrites:
....
Is that a challenge? Throw a declaration at me so, one I can't make head nor
tails of.
The following is a bit complicated:
void (*(*f)(int (*)(int)))(int (*)());
cdecl has no problems with it.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 3 '06 #22

P: n/a
Christopher Benson-Manica said:
Richard Heathfield <in*****@invalid.invalidwrote:
>Frederick Gotham said:
(snip)
>I declare that you owe several people in this newsgroup an apology.

Again, would it be possible to identify these posts which consist of
nothing more than seemingly hopeless attempts to induce some measure
of civility in Mr. Gotham?
Sorry, Christopher. The opening was just too obvious to ignore. But I hope
you'll agree that the frequency of such posts has dropped dramatically,
presumably because people realise he is, as you suggest, a lost cause.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 3 '06 #23

P: n/a
CBFalconer <cb********@yahoo.comwrote:
Richard Heathfield wrote:
Frederick Gotham said:
Throw a declaration at me so, one I can't make head nor tails of.
I declare that you owe several people in this newsgroup an apology.

That definitely fits, as he has demonstrated his inability to
comprehend that multiple times.
Possibly, but do you guys _have_ to keep wittering on about it? FFS,
you're getting to be as tiresome as Kenny.

Richard
Nov 3 '06 #24

P: n/a
Dik T. Winter:
The following is a bit complicated:
void (*(*f)(int (*)(int)))(int (*)());
cdecl has no problems with it.
Yippie! I'll think out loud, if you don't mind.

Okay, I see "f", so I know that the name of the entire entity is "f".
It has an asterisk directly to its left and both are enclosed within
parentheses, so it must be a pointer.

(Now, in my mind, I'll replace (*f) with simply f.)

Now I'm looking at:

void (*f(int (*)(int)))(int (*)());

I see that f has parentheses containing types directly to its right, so it
must be a function. (I haven't looked at the asterisk to its left yet
because the parentheses have higher precedence). The function has the
following sole parameter:

int (*)(int)
This is a pointer to an int-returning-function whose sole parameter is
an int.

(Now in my mind, I'll replace f(int (*)(int)) with simply f.)

Now, I'm looking at:

void (*f)(int (*)());

I now see that f has an asterisk directly to its left, and both are
enclosed in parentheses, so f must be a pointer.

(Now in my mind, I'll replace (*f) with simply f.)

Now I'm looking at:

void f(int(*)());

This is a void-returning-function whose sole parameter is a pointer to an
int-returning-function whose parameter list is void. (The empty-parentheses
variable-parameter-list rule doesn't apply because we're not dealing with
the declaration of an actual existant function). Therefore, it's equivalent
to:

void f(int(*)(void));

So if I put them all togther, I have:

(1) f is a pointer.
(2) f is a function whose sole parameter is a pointer to an int-returning-
function whose sole parameter is an int.
(3) f is a pointer.
(4) f is a void-returning-function whose sole parameter is a pointer to an
int-returning-function whose parameter list is void.

To simplify the entire thing with typedef's, we work backwards. First of
all though, I want to get rid of those pesky function pointer types:

typedef int (*FuncPtr1)(int);
typedef int (*FuncPtr2)(void);

Now we can work backwards from (4) above:

typedef void T4(FuncPtr2);
typedef T4 *T3;
typedef T3 T2(FuncPtr1);
typedef T2 *T1;

If the compiler doesn't give us a type-mismatch, then we've probably done
it right:

typedef int (*FuncPtr1)(int);
typedef int (*FuncPtr2)(void);
typedef void T4(FuncPtr2);
typedef T4 *T3;
typedef T3 T2(FuncPtr1);
typedef T2 *T1;

int main(void)
{
/* First let's make an object of the original type. */

void (*(*f)(int (*)(int)))(int (*)()) = 0;

/* Now let's make an object of our own type. */

T1 obj = 0;

/* Now let's see if we get a type-mismatch when
we try to assign them. */

f = obj;
obj = f;

return 0;
}

It shouldn't be too hard to work with the type now. I'd post example code,
but I can't think of any contrived usage which wouldn't come across as
utterly facetious (given the obscure nature of the type in question).

--

Frederick Gotham
Nov 3 '06 #25

P: n/a
Richard Heathfield <in*****@invalid.invalidwrote:
Sorry, Christopher. The opening was just too obvious to ignore. But I hope
you'll agree that the frequency of such posts has dropped dramatically,
presumably because people realise he is, as you suggest, a lost cause.
Yes, I do agree that the number of such posts has been on the decline.
I suppose the "grin and bear it" option isn't too unpalatable at this
point. (And yes, he did leave you with a rather obvious rejoinder...)

Thanks.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Nov 3 '06 #26

P: n/a
Dik T. Winter wrote:
In article <ei**********@chessie.cirr.comChristopher Benson-Manica
<at***@otaku.freeshell.orgwrites:
>Again, would it be possible to identify these posts which consist of
nothing more than seemingly hopeless attempts to induce some measure
of civility in Mr. Gotham?
If you have a newsreader that can filter based on content rather than
headers (I have), there is no problem.

I think it's pretty unreasonable to request that people do that. Even
for those that have the capability, it's a tremendous slow-down in
newsreading to scan message bodies.
Mr. Heathfield took people to task for what he deemed a worsening the
signal to noise ratio of the group when complaining solely about
top-posting. I think what he's doing is every bit as bad (as are his
interminable arguments with Mr. Navia). Marking the subject line is
quite reasonable, and is what I offered to do to resolve HIS
complaints. A similar accomodation from him would be welcome.


Brian
Nov 3 '06 #27

P: n/a
"Default User" <de***********@yahoo.comwrites:
[...]
Mr. Heathfield took people to task for what he deemed a worsening the
signal to noise ratio of the group when complaining solely about
top-posting. I think what he's doing is every bit as bad (as are his
interminable arguments with Mr. Navia). Marking the subject line is
quite reasonable, and is what I offered to do to resolve HIS
complaints. A similar accomodation from him would be welcome.
Mr. Heathfield already apologized in this thread. If you missed it:

| Sorry, Christopher. The opening was just too obvious to ignore. But I hope
| you'll agree that the frequency of such posts has dropped dramatically,
| presumably because people realise he is, as you suggest, a lost cause.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 3 '06 #28

P: n/a
Keith Thompson wrote:
"Default User" <de***********@yahoo.comwrites:
[...]
Mr. Heathfield took people to task for what he deemed a worsening
the signal to noise ratio of the group when complaining solely about
top-posting. I think what he's doing is every bit as bad (as are his
interminable arguments with Mr. Navia). Marking the subject line is
quite reasonable, and is what I offered to do to resolve HIS
complaints. A similar accomodation from him would be welcome.

Mr. Heathfield already apologized in this thread. If you missed it:
That appeared later in the thread as I viewed. The general point stands
though.

Brian
Nov 3 '06 #29

P: n/a
Default User said:

<snip>
>
Mr. Heathfield took people to task for what he deemed a worsening the
signal to noise ratio of the group when complaining solely about
top-posting.
Yes, since it was becoming a significant proportion of the traffic.
I think what he's doing is every bit as bad
That's your privilege, but (a) the volume isn't actually all that high, and
(b) it has declined rapidly, as I have effectively given up on the guy ever
gaining a clue.
(as are his
interminable arguments with Mr. Navia).
I can't help it if the guy is almost always wrong. But in any case, other
people seem to have noticed that he's almost always wrong, so I don't need
to point out his errors quite so often - the load is distributed more
evenly nowadays.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 3 '06 #30

P: n/a
Richard Heathfield wrote:
Default User said:

<snip>

Mr. Heathfield took people to task for what he deemed a worsening
the signal to noise ratio of the group when complaining solely about
top-posting.

Yes, since it was becoming a significant proportion of the traffic.
No, it wasn't. Especially not compared to some of your interminable
arguments with people.
I think what he's doing is every bit as bad

That's your privilege, but (a) the volume isn't actually all that
high, and (b) it has declined rapidly, as I have effectively given up
on the guy ever gaining a clue.
Fine.
(as are his
interminable arguments with Mr. Navia).

I can't help it if the guy is almost always wrong. But in any case,
other people seem to have noticed that he's almost always wrong, so I
don't need to point out his errors quite so often - the load is
distributed more evenly nowadays.
Correcting him on factual matters is a good thing - once. Protracted
arguments aren't. There have been a number of times where I looked at a
newsgroup thread and saw 20 or more posts, the vast majority coming
from two people: Richard Heathfield and Jacob Navia. You can't convince
of anything.

Brian
Nov 4 '06 #31

P: n/a
In article <KV*******************@news.indigo.ieFrederick Gotham <fg*******@SPAM.comwrites:
Dik T. Winter:
The following is a bit complicated:
void (*(*f)(int (*)(int)))(int (*)());
cdecl has no problems with it.
....
Now all those f's below are a bit confusing:
(1) f is a pointer.
(2) f is a function whose sole parameter is a pointer to an int-returning-
function whose sole parameter is an int.
(3) f is a pointer.
(4) f is a void-returning-function whose sole parameter is a pointer to an
int-returning-function whose parameter list is void.
(1) and (2) are correct, but this description makes not clear what the
original f does return.
....
It shouldn't be too hard to work with the type now. I'd post example code,
but I can't think of any contrived usage which wouldn't come across as
utterly facetious (given the obscure nature of the type in question).
Obscure? From signal.h under Solaris:
int (*sigset(int, int (*)(int)))(int);
I think that declaration has been in there since BSD times. If f were
declared as:
int (*(*(*f)(int (*)(int)))(int, int (*)(int)))(int);
it might have been a function that took as parametera sighandler and
returned something of the type of sigset.

cdecl is quite handy at times. For the one I gave above:
cdeclexplain void (*(*f)(int (*)(int)))(int (*)());
declare f as pointer to function (pointer to function (int) returning int)
returning pointer to function (pointer to function returning int)
returning void
cdecl>
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 4 '06 #32

P: n/a
On 4 Nov 2006 00:27:02 GMT, "Default User" <de***********@yahoo.com>
wrote:
>No, it wasn't. Especially not compared to some of your interminable
arguments with people.
Speaking of interminable arguments, let's stop this one.

--
Al Balmer
Sun City, AZ
Nov 4 '06 #33

P: n/a
Dik T. Winter:
Now all those f's below are a bit confusing:
(1) f is a pointer.
(2) f is a function whose sole parameter is a pointer to an
int-returning- function whose sole parameter is an int.
(3) f is a pointer.
(4) f is a void-returning-function whose sole parameter is a pointer
to an int-returning-function whose parameter list is void.
(1) and (2) are correct, but this description makes not clear what the
original f does return.

That's because the return value is dependant upon the rest of the
breakdown.

It shouldn't be too hard to work with the type now. I'd post example
code, but I can't think of any contrived usage which wouldn't come
across as utterly facetious (given the obscure nature of the type in
question).

Obscure? From signal.h under Solaris:
int (*sigset(int, int (*)(int)))(int);

This is far less obscure. It's simply a function which takes a function
pointer and returns one:

typedef int (*FuncPtr)(int);

FuncPtr sigset(int,FuncPtr);

--

Frederick Gotham
Nov 4 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.