Why no generic function pointers?

[Tor Rustad]

Re: Why no generic function pointers?

Eric Sosman skrev:

[...]

>
And in strictly-conforming C you can cast any function pointer
to any other function pointer type and back again. What's your beef?

Sure can, but isn't a cast needed?


OTOH, a cast isn't needed to void* convert to another
(pointer-to-object) type.


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

[Ben Bacarisse]

Re: Why no generic function pointers?

"Bartc" <bc@freeuk.comw rites:

"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message
news:87hcbnt2kz .fsf@bsb.me.uk. ..

>"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>>

>>"copx" <copx@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).

>
How would that work?

I think Malcolm has covered this but it seems there may have been a
misunderstandin g so let me jump in...

Suppose I have my function pointer fnptr. And I have N
(known only at runtime) arguments from an array, say, to pass it. How can I
have a loop pushing just the parameters I need?
>
I have an actual need for this; at the moment I'm doing stuff like this
(assume fn is a valid function call):
>
switch (N) {
case 0: result=fn(); break;
case 1: result=fn(param s[0]); break;
case 2: result=fn(param s[0],params[1]); break;
...
up to some limit.
>
(and the whole thing repeated for different calltypes of fn; and repeated
again for different return type of fn: int-sized or double)

My suggestion does not help in this sort of case. In your case, I
would have been inclined to make fn of type

int (*ifunction)(si ze_t n, int *args);

and thus the call becomes simply 'result = fn(N, params);'. Of course
you may have been constrained in that the functions already exist and
you didn't want to wrap them. If that was the case, neither the above,
nor my varargs suggestion will be of any help.

My suggestion, of building a va_list, is of very limited use. There
are almost always better ways to do it, but it would allow simple
wrappers round the various va_list taking function to be used as
built-in functions in table-driven interpreted languages. Since it is
of limited utility, it is unlikely to become available so the
discussion is largely for entertainment value only.

--
Ben.

[Ben Bacarisse]

Re: Why no generic function pointers?

Tor Rustad <tor_rustad@hot mail.comwrites:

Eric Sosman skrev:
>
[...]

> And in strictly-conforming C you can cast any function pointer
>to any other function pointer type and back again. What's your beef?

>
Sure can, but isn't a cast needed?
>
OTOH, a cast isn't needed to void* convert to another
(pointer-to-object) type.

Forgive me if I have got the wrong end of the stick, but you seem to
be suggesting it would be nice if the cast on function pointers (or
void *s where that is supported as an extension) could be avoided. I
can't see how it could be. If the type is not already exactly right,
the required type can not be inferred from the rules C has.

Maybe your "beef" is that you wish the rules were different and the
required type of the pointer could simply be deduced from the call.
If so, then I think you are asking for quite a different language.

--
Ben.

[Keith Thompson]

Re: Why no generic function pointers?

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

Tor Rustad <tor_rustad@hot mail.comwrites:

>Eric Sosman skrev:
>[...]

>> And in strictly-conforming C you can cast any function pointer
>>to any other function pointer type and back again. What's your beef?

>>
>Sure can, but isn't a cast needed?
>>
>OTOH, a cast isn't needed to void* convert to another
>(pointer-to-object) type.

>
Forgive me if I have got the wrong end of the stick, but you seem to
be suggesting it would be nice if the cast on function pointers (or
void *s where that is supported as an extension) could be avoided. I
can't see how it could be. If the type is not already exactly right,
the required type can not be inferred from the rules C has.
>
Maybe your "beef" is that you wish the rules were different and the
required type of the pointer could simply be deduced from the call.
If so, then I think you are asking for quite a different language.

If the cast were not required for converting function pointer types,
in the same manner that it's not required for void*, then you could do
an implicit conversion via an assignment (or, equivalently, an
initialization or passing an argument). A function call just isn't
one of the assignment-like contexts where there's enough information
to determine the target type (and it happens to be the context where
the conversion would be most useful).

On the other hand, if such an implicit conversion *were* possible, it
would be way too easy to violate type safety in indirect function
calls.

--
Keith Thompson (The_Other_Keit h) 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"

[Tor Rustad]

Re: Why no generic function pointers?

Ben Bacarisse skrev:

Maybe your "beef" is that you wish the rules were different and the
required type of the pointer could simply be deduced from the call.
If so, then I think you are asking for quite a different language.

The standard is silent on issues regarding compile-time and run-time
linking.


What a C programmer want, is to be able to load libraries/modules and
symbols dynamically, and do so without a cast.


i don't see why this require a different language. It is not impossible
to put the burdon on implementations on providing _some_ run-time checks
for type-safety -- in case a generic function pointer was to be used in
such a context.


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

[Ben Bacarisse]

Re: Why no generic function pointers?

Tor Rustad <tor_rustad@hot mail.comwrites:

Ben Bacarisse skrev:
>

>Maybe your "beef" is that you wish the rules were different and the
>required type of the pointer could simply be deduced from the call.
>If so, then I think you are asking for quite a different language.

>
The standard is silent on issues regarding compile-time and run-time
linking.
>
What a C programmer want, is to be able to load libraries/modules and
symbols dynamically, and do so without a cast.
>
i don't see why this require a different language.

As Keith Thompson's message points out, assignment-like contexts
provide enough type information that C *could* allow the conversion
from one function type to another without a cast.

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.

It is not
impossible to put the burdon on implementations on providing _some_
run-time checks for type-safety -- in case a generic function pointer
was to be used in such a context.

Anything that requires a run-time check seems to run counter to the
spirit of C.

--
Ben.

[Wolfgang Draxinger]

Re: Why no generic function pointers?

Malcolm McLean wrote:

>
"copx" <copx@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. You can
hardcode

I beg to differ:

http://www.haible.de/bruno/packages-ffcall.html

Sure, it's not implemented purely in C, but that doesn't matter:
It provides a C interface to build argument lists on the fly.
Personally I make heavy use of it in adapting script
interpreters to C modules.

Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@jabber .org, ICQ: 134682867

[Kenny McCormack]

Re: Why no generic function pointers?

In article <bkq1j5-a8v.ln1@darksta rgames.dnsalias .net>,
Wolfgang Draxinger <wdraxinger@dar kstargames.dewr ote:

>Malcolm McLean wrote:
>

>>
>"copx" <copx@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. You can
>hardcode

>
>I beg to differ:
>http://www.haible.de/bruno/packages-ffcall.html
>
>Sure, it's not implemented purely in C, but that doesn't matter:
>It provides a C interface to build argument lists on the fly.
>Personally I make heavy use of it in adapting script
>interpreters to C modules.

Yes. I have mentioned ffcall (aka, avcall) many times here. It is very
nice. But, of course, the regs aren't interested.

[Tor Rustad]

Re: Why no generic function pointers?

Ben Bacarisse skrev:

Tor Rustad <tor_rustad@hot mail.comwrites:
>

>Ben Bacarisse skrev:
>>

>>Maybe your "beef" is that you wish the rules were different and the
>>required type of the pointer could simply be deduced from the call.
>>If so, then I think you are asking for quite a different language.

>The standard is silent on issues regarding compile-time and run-time
>linking.
>>
>What a C programmer want, is to be able to load libraries/modules and
>symbols dynamically, and do so without a cast.
>>
>i don't see why this require a different language.

>
As Keith Thompson's message points out, assignment-like contexts
provide enough type information that C *could* allow the conversion
from one function type to another without a cast.

Keith's point appeared meaningless to me, because today we are forced to
do a cast, and by doing so, we shut down type checks.

Hence, if there was a generic function pointer, the matter will not get
worse, since implementations can add type-safety checks which don't need
to be shut down by such a cast.

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.

It a QoI issue, how well a run-time loader does this job.

>It is not
>impossible to put the burdon on implementations on providing _some_
>run-time checks for type-safety -- in case a generic function pointer
>was to be used in such a context.

>
Anything that requires a run-time check seems to run counter to the
spirit of C.

Checks are already needed today by the run-time loader. This isn't
rocket science, on implementations supporting dynamically loadable
libraries, the run-time loaders typically locate functions via symbolic
search.

Now, by decorating the exported function symbols, type-safety can be
added for explicit linking, without any significant extra overhead
compared with what there is already.

I'm aware that symbols can be stripped, but that is like instructing the
compiler to export functions in a library with a cast, and just make
function relative addresses visible to the world outside.

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

[Keith Thompson]

Re: Why no generic function pointers?

Wolfgang Draxinger <wdraxinger@dar kstargames.dewr ites:

Malcolm McLean wrote:

>"copx" <copx@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. You can
>hardcode

>
I beg to differ:

http://www.haible.de/bruno/packages-ffcall.html

>
Sure, it's not implemented purely in C, but that doesn't matter:
It provides a C interface to build argument lists on the fly.
Personally I make heavy use of it in adapting script
interpreters to C modules.

But be careful. Quoting the "Bugs" section of the avcall man page:

* The current implementations have been tested on a selection of
common cases but there are probably still many bugs.

* There are typically built-in limits on the size of the
argument-list, which may also include the size of any structure
arguments.

* The decision whether a struct is to be returned in registers or
in memory considers only the struct's size and alignment. This
is inaccurate: for example, gcc on m68k-next returns struct {
char a,b,c; } in registers and struct { char a[3]; } in memory,
although both types have the same size and the same alignment.

I don't believe it's possible to do what avcall does in entirely
portable C. If the benefits outweigh the limitations for your
particular use, that's fine.

--
Keith Thompson (The_Other_Keit h) 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"

[Walter Roberson]

Re: Why no generic function pointers?

In article <2L6dnXni7oFHgc PVRVnzvQA@telen or.com>,
Tor Rustad <tor_rustad@hot mail.comwrote:

>What a C programmer want, is to be able to load libraries/modules and
>symbols dynamically, and do so without a cast.

We do???

I don't recall a single instance in which I found providing
the cast to be a burden.
--
"What we have to do is to be forever curiously testing new
opinions and courting new impressions." -- Walter Pater

[Kenny McCormack]

Re: Why no generic function pointers?

In article <5bOdnYCIT6Rm_c PVRVnzvQA@telen or.com>,
Tor Rustad <tor_rustad@hot mail.comwrote:
....

>
>Keith's point appeared meaningless to me, because today we are forced to
>do a cast, and by doing so, we shut down type checks.

Most of Keith's posts are (totally) meaningless. But they are always
fun to read, and, in fact, I now explicitly do a "select" (in my
"killfile") on articles written by him.

[Chris Torek]

Re: Why no generic function pointers?

>Wolfgang Draxinger <wdraxinger@dar kstargames.dewr ites:

>Sure, it's not implemented purely in C ...

Significant pieces are not in C at all :-)

In article <lnod5t7c8z.fsf @nuthaus.mib.or g>
Keith Thompson <kst-u@mib.orgwrote:

>I don't believe it's possible to do what avcall does in entirely
>portable C. ...

Indeed not. (But if what it does do, non-portably, is good enough
for what you want done, that is obviously sufficient. The time to
worry is when you need it to do more, or to work on another machine.
It should always be possible to make it work there, but it may take
some effort, and possibly modifications to whatever code you have
that uses avcall as well as to avcall itself.)

Here is an example of part of the code (I do not know why it
has its own private offsetof when the <stdlib.hversio n should
work here):

#include "avcall.h.i n"

#define RETURN(TYPE,VAL ) (*(TYPE*)l->raddr = (TYPE)(VAL))
#define OFFSETOF(struct ,member) ((int)&(((struc t*)0)->member))

register void* callee __asm__("%g2"); /* any global or local register */
register __avword o0 __asm__("%o0");
register __avword o1 __asm__("%o1");
register __avword o2 __asm__("%o2");
register __avword o3 __asm__("%o3");
register __avword o4 __asm__("%o4");
register __avword o5 __asm__("%o5");

int
__builtin_avcal l(av_alist* l)
{
register __avword* sp __asm__("%sp"); /* C names for registers */
register float fret __asm__("%f0"); /* %f0 */
register double dret __asm__("%f0"); /* %f0,%f1 */

__avword trampoline[6]; /* room for a trampoline */
__avword space[__AV_ALIST_WORD S]; /* space for callee's stack frame */
__avword *argframe = sp + 17; /* stack offset for argument list */
int arglen = l->aptr - l->args;
__avword i;

if (l->farg_mask) {
/* push leading float args */
if (l->farg_mask & (1<<0))
__asm__("ld %1(%0),%%f1" : : "p" (l), "i" OFFSETOF(av_ali st,args[0]));
[rest snipped]

This is not only gcc-specific, it also does not compile on your%
machine, even if you have gcc. :-) It is not really C code at
all, but rather assembly code with a C skeleton.

(Of course, there is a different version for your% machine.)

[% By "your" I mean "you, the person reading this news article".
There may be a few rare readers -- perhaps Eric Sosman, for instance
-- for whom this statement is untrue, though.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Ben Bacarisse]

Re: Why no generic function pointers?

Tor Rustad <tor_rustad@hot mail.comwrites:

Ben Bacarisse skrev:

>Tor Rustad <tor_rustad@hot mail.comwrites:
>>

>>Ben Bacarisse skrev:
>>>
>>>Maybe your "beef" is that you wish the rules were different and the
>>>required type of the pointer could simply be deduced from the call.
>>>If so, then I think you are asking for quite a different language.
>>The standard is silent on issues regarding compile-time and run-time
>>linking.
>>>
>>What a C programmer want, is to be able to load libraries/modules and
>>symbols dynamically, and do so without a cast.
>>>
>>i don't see why this require a different language.

>>
>As Keith Thompson's message points out, assignment-like contexts
>provide enough type information that C *could* allow the conversion
>from one function type to another without a cast.

>
Keith's point appeared meaningless to me, because today we are forced
to do a cast, and by doing so, we shut down type checks.
>
Hence, if there was a generic function pointer, the matter will not
get worse, since implementations can add type-safety checks which
don't need to be shut down by such a cast.

I am getting confused as to what point you want to make. Maybe you
should give an example. I wrote a lot then deleted it because I think
we are talking at cross purposes. What would like to see that would help?

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

The compiler might have to generate different code depending on whether
fp points to void fd(double) {...} or void fi(int) {...}.

Of course, if the real type of the pointed-to function is carried
around at run-time the correct call can be made, but that is not in the
spirit of C.

--
Ben.

[pete]

Re: Why no generic function pointers?

Chris Torek wrote:

Here is an example of part of the code (I do not know why it
has its own private offsetof when the <stdlib.hversio n should
work here):

<stddef.hversio n

offsetof is portable for freestanding
as well as hosted implementations .

--
pete