Question about C Functions

[Dik T. Winter]

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

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

 

[Richard Heathfield]

Christopher Benson-Manica said:

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 Bos]

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

 

[Christopher Benson-Manica]

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.

 

[Frederick Gotham]

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

 

[Default User]

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

 

[Keith Thompson]

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.

 

[Default User]

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

 

[Richard Heathfield]

Default User said:

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.

 

[Default User]

Default User said:



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.

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.


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

 

[Dik T. Winter]

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

> 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:
cdecl> explain 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>

 

[Al Balmer]

No, it wasn't. Especially not compared to some of your interminable
arguments with people.

Speaking of interminable arguments, let's stop this one.

 

[Frederick Gotham]

Dik T. Winter:

Now all those f's below are a bit confusing:
(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.

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);