get the address of a function??

[Herbert Rosenau]

Yeah, but I count one error, not two.

Unless you're saying all of the following are therefore invalid
int main() { }
int main(c,v) char **v; { }

Allowed in K&R C. tolerated in C89, illegal in C99.

main() { }
main(c,v) char **v; { }

illegal in C99.

main(void) { }
[and other combinations]

Depends on the standard you use for compile.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

2006-11-04 <[email protected]>,


Not really. on a POSIX system, or really anything that supports dlsym,
conversion between function pointers and void * is defined anyway.

No. void* may even not wide enough to hold an address of a function.
Trying to convert a pointer to a function to anything else than to a
pointer to a function of same or another type is undefined behavior.
Like any undefined behavior it may work on your system but it may
result in flying demons out of your nose.

You can do with a function
- call it
- create a function pointer and assign its address to it
- create a function pointer to a function pointer and assign
the address of a function pointer to it - and so on.

You can't do without ending in the lands of undefined behavior:
- assign the address of a function to an pointer of any type that is
not a pointer to function
- convert a pointer to data to a pointer to function.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Richard Tobin]

Not really. on a POSIX system, or really anything that supports dlsym,
conversion between function pointers and void * is defined anyway.

[/QUOTE]

No. void* may even not wide enough to hold an address of a function.

Then apparently such a system cannot support POSIX.

Trying to convert a pointer to a function to anything else than to a
pointer to a function of same or another type is undefined behavior.

Undefined by C. But most systems don't only support C.

-- Richard

 

[Keith Thompson]

No. void* may even not wide enough to hold an address of a function.

Did you miss the "on a POSIX system" qualification?

The C standard doesn't require void* to be wide enough to hold the
address of a function. <OT>POSIX imposes additional requirement.</OT>

 

[Flash Gordon]

No. void* may even not wide enough to hold an address of a function.
Trying to convert a pointer to a function to anything else than to a
pointer to a function of same or another type is undefined behavior.
Like any undefined behavior it may work on your system but it may
result in flying demons out of your nose.

Read again what Jordan wrote. He was specifically talking about POSIX
systems or other systems that provide a POSIX like dlsym() function. On
such systems dlsym is defined (by the implementation) as returning a
function pointer but has a return type of void*. The POSIX standard, and
any other system providing a similar dlsym() function, therefore defines
a conversion between function pointers and void*. So on such a system
you *can* do the conversion in safety. On a system without dlsym you
could not use dlsym. So Jordan was correct to say that using dlsym() was
not really a work around because it would only work where you are
*guaranteed* by the implementation not to need it.

Implementations are specifically allowed to define anything the
implementation leaves (or specifies as) undefined behaviour.

As far as the C standard is concerned it is, of course, undefined.
However, the C standard does not define what happens if you call a
system provided dlsym function either.

There are, of course, solutions to the problem the OP had that do not
rely on things outside the C standard and these have been posted by
others already.

 

[Herbert Rosenau]

No. void* may even not wide enough to hold an address of a function.

Then apparently such a system cannot support POSIX.

Trying to convert a pointer to a function to anything else than to a
pointer to a function of same or another type is undefined behavior.

Undefined by C. But most systems don't only support C.[/QUOTE]

This group has nothing to do with any< system - it is related to C. So
saying this or that system is not related on something the standard
requires or defies as undefined is of no relevance at all.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Did you miss the "on a POSIX system" qualification?

What has POSIX to do with the C standard?

The C standard doesn't require void* to be wide enough to hold the
address of a function. <OT>POSIX imposes additional requirement.</OT>

May be, may be not, bot this group has nothing to do with POSIX at
all. When POSIX is not standard compilant then it is completely off
topic here.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

What has POSIX to do with the C standard?

POSIX is based on the C standard.

<ON-TOPIC>
A secondary standard, or a particular implementation, is allowed to
impose additional requirements not imposed by the C standard itself.
In particular, it may define the behavior of constructs whose behavior
is undefined by the C standard. For example, a function that returns
a void* intended to be used as a function pointer cannot be portable,
but it can be specified by a secondary standard or by a particular
implementation. Any code that uses such a function is portable only
to that implementation, or to systems that support that secondary
standard.
</ON-TOPIC>

<OFF-TOPIC>
The dlsym() function specified by POSIX is an example of this.

May be, may be not, bot this group has nothing to do with POSIX at
all. When POSIX is not standard compilant then it is completely off
topic here.

I'm not convinced it's *completely* off-topic. I'd say it's topical
to the extent that it illustrates a point about extensions. The
standard explicitly permits extensions, after all.

But even if it's completely off-topic, it would have been better to
point out that it's off-topic rather than to pretend that the phrase
"on a POSIX system" wasn't there.

You response:

No. void* may even not wide enough to hold an address of a function.

is true in the context of standard C, but the question was clearly
limited to the context of POSIX systems. In effect, you responded to
an off-topic question with a response that was both off-topic and
incorrect.

 

[Richard Tobin]

Then apparently such a system cannot support POSIX.
Undefined by C. But most systems don't only support C.

[/QUOTE]

This group has nothing to do with any< system - it is related to C. So
saying this or that system is not related on something the standard
requires or defies as undefined is of no relevance at all.

Whether it's relevant is irrelevant to the fact that your statement
"No" is false, since the context was a POSIX system regardless of
what this group is about.

-- Richard

 

[Jordan Abel]

No. void* may even not wide enough to hold an address of a function.

On a POSIX system, it is. It's in that _other_ standard, you know? So
using dlsym (which is the reason why POSIX requires it) trickery for
this purpose is beyond silly. Either it'll work or dlsym() won't.

 

[Guest]

On a POSIX system, it is. It's in that _other_ standard, you know? So
using dlsym (which is the reason why POSIX requires it) trickery for
this purpose is beyond silly. Either it'll work or dlsym() won't.

dlsym() is part of the XSI extension to POSIX, not of POSIX itself. (I
know a lot of people posted that POSIX requires it, so this is not
directed at you in particular.)

 

[Jordan Abel]

dlsym() is part of the XSI extension to POSIX, not of POSIX itself. (I
know a lot of people posted that POSIX requires it, so this is not
directed at you in particular.)

Well, my point was rather "dlsym is never useful for this, because if
dlsym is available, you can cast it to void* anyway", so it still
stands. (And I seem to recall that POSIX still requires function pointer
to void*, but I could be wrong)

 

[Richard Bos]

I don't think so. A function pointer may be a large involved
thing, such as fields for segment, offset, in/out_ofmemory, etc. I
don't think sizeof can cope with this.

If it didn't, you couldn't have arrays of function pointers.

Richard

 

[Joe Wright]

If it didn't, you couldn't have arrays of function pointers.

Richard

Very good point. Bos is boss.

 

[Richard Bos]

Very good point. Bos is boss.

No, Bos is Wood.

Richard