Why no generic function pointers?

[copx]

Why doesn't the C standard include generic function pointers?

I use function pointers a lot and the lack of generic ones is not so cool.

There is a common compiler extension (supported by GCC and lccwin32 for example)
which I consider to be perfectly reasonable: you can cast every kind of function pointer
to a void pointer and void pointers to any kind of function pointer.

This follows the general "generics through void scheme" of C. In fact, it seems to be quite
"irregular" to me that you can't cast function pointers to void.

I mean, of course, generic function pointers are "dangerous" , because they allow
you to call a function with bad arguments and the compiler can't detect that.
But it's not any more "dangerous" than unsigned char pointers to any type of data i.e.
not against the "C spirit" IMO.

In fact, K&R compilers supported semi-generic function pointers IIRC. You were
able to leave out the parameter declaration (but not the return type declaration) e.g.
int (*foo)();

So why did the comittee decide against making generic function pointers standard?

[Tor Rustad]

Ben Bacarisse skrev:

Tor Rustad <to********@hot mail.comwrites:

>Ben Bacarisse skrev:

[...]

>>Just to be clear, I was focusing on the function call. At that point,
there is not enough information for the compiler to generate a correct
call, at least not in the most general case.

The compiler can very much generate the correct call, BUT it's a
different matter if such a function exist, and this is the job of the
run-time loader to detect.

I was making a narrow technical point: given a generic function
pointer type, a C function call does not have the information required
to check the type and generate the correct calling code. Assume fp is
such a generic pointer. What is the type of function being called
here:

fp(12.3);

Ohh..no

we can't do pointer arithmetic on pointer-to-void either:

void foo(void *p)
{
(*(char *)p)++;
}

so I don't see why you assume I somehow suggest that calling a "generic
function pointer" to be meaningful.
Converting a function pointer to some "generic function pointer", would
throw away information, while converting a "generic function pointer" to
a function pointer, would add information.

I don't see why such conversion should be explicit (i.e. require a
cast), other than as providing a comment for humans (that is, if typedef
of the function pointer is used, else not very readable).
Hmm.. another possibly useful thing with a "generic function pointer",
could be to hold functions (of different types) in a jump table:

gen_func_t jmp[3] = {f1, f2, f3};
Anyway, this is rather academic... in ca. 99,99% IRL cases, void* will
work fine as a generic function pointer. :)

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[Ben Bacarisse]

Tor Rustad <bw****@wvtqvm. vwwrites:

Ben Bacarisse skrev:

>Tor Rustad <to********@hot mail.comwrites:

>>Ben Bacarisse skrev:

[...]

>>>Just to be clear, I was focusing on the function call. At that point,
there is not enough information for the compiler to generate a correct
call, at least not in the most general case.
The compiler can very much generate the correct call, BUT it's a
different matter if such a function exist, and this is the job of the
run-time loader to detect.

I was making a narrow technical point: given a generic function
pointer type, a C function call does not have the information required
to check the type and generate the correct calling code. Assume fp is
such a generic pointer. What is the type of function being called
here:

fp(12.3);

Ohh..no

we can't do pointer arithmetic on pointer-to-void either:

void foo(void *p)
{
(*(char *)p)++;
}

so I don't see why you assume I somehow suggest that calling a
"generic function pointer" to be meaningful.

I wasn't. I was trying to explain what I was saying. It may well
have had nothing to do with what you were saying -- these things
happen on Usenet! That is why I asked for an example of what you
want...

Converting a function pointer to some "generic function pointer",
would throw away information, while converting a "generic function
pointer" to a function pointer, would add information.

I don't see why such conversion should be explicit (i.e. require a
cast), other than as providing a comment for humans (that is, if
typedef of the function pointer is used, else not very readable).

Now I see what you are saying. You want a pointer type to (and from)
which any function pointer can be converted without a cast. This
would help a little, I agree.

I though you were suggesting that the forced cast somehow prevented
some type checking that could otherwise be done.

--
Ben.

[Dann Corbit]

"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..

"Malcolm McLean" <re*******@btin ternet.comwrite s:

>"copx" <co**@gazeta.pl wrote in message

>>Why doesn't the C standard include generic function pointers?

Because you can't build an argument list on the fly.

That begs the question of why one can't do *that*. There are macros
to examine an existing var-arg list, and there the could be macros to
build one from scratch. Given such a thing, a function pointer type
like:

void *(*var_arg_fp)( void *, ...);

would be very flexible (you need a dummy first argument to get the var
arg macros going).

I presume the answer is just history. Of course, it may be that there
are real systems for which such argument building macros/functions
would be impossible, but the seems a stretch.

For some compilers, functions with varadic argument lists and other function
types can be treated differently.

For instance, I can tell one compiler that I want to pass arguments as
registers when possible. If the function is varadic, then that convention
will not be used (and it will definitely cause problems if a prototype is
not in scope and the warning is ignored).

So I think it is up to the compiler vendor to decide exactly how generic a
pointer to function type might be.
** Posted from http://www.teranews.com **