Re: pointer casts

On Wed, 13 Mar 2002, Owen Taylor wrote:

> "Dan Maas" <dmaas dcine com> writes:
> > > > GCC has a non-standard extension that allows implicit casts
> > > > betweeen (void *) and any function pointers.
> > >
> > > "Even with an explicit cast, it is invalid to convert a function
> > > pointer to an object pointer or a pointer to void, or vice versa."
> > 
> > Violations of this rule could show up as a problem on architectures where
> > function pointers are "special," e.g. IA-64 and PPC64. Is GTK working on
> > these arches?
> GTK+-2.0 has had some testing on IA-64... it certainly compiles and
> the tools used in compilation work.
> As far as I understand, while function pointers on IA-64 don't point
> directly to the code address (they point to a "function descriptor"),
> they still are 64-bits and should be fine to store temporarily in a
> void *.
> No idea about PPC64, but my guess is that any architecture that broke
> the size equivalence of function and normal pointers would be "exotic"
> enough to cause problems for a lot of software.

Like (probably) AIX on anything? Its more or less the question of what
your ABI looks like, and certain people feel the need to have an ABI where
function invocations involve an additional pointer. AFAIK, function
pointers are still just pointers and the compiler can do all the the
necessary steps at code generation time.

These are sort-of half-way between making function pointers be special,
also it is *NOT* an architecure level problem there (as opposed to say
(iirc) crays) but just the way the abi and call conventions on the OSs
work. Some other OS/toolchain combination on the same platform need not
have such.

> Regards,
>                                         Owen


	I see a dark sail on the horizon
	Set under a dark cloud that hides the sun
	Bring me my Broadsword and clear understanding

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]