Re: (object (*)()) vs (long (*)())
Richard Zidlicky <Richard.Zidlicky@stud.informatik.uni-erlangen.de> writes:
|> cc'd linux-m68k as this seems more appropriate for ABI related
|> questions.
|>
|> On Tue, Jul 30, 2002 at 01:42:17PM -0400, Camm Maguire wrote:
|> > Greetings! I'm maintaining gcl, which, fortunately or not, relies on
|> > being able to cast function results back and forth from long to void
|> > *.
Better use intptr_t/uintptr_t. These are guaranteed to not lose any
pointer bits, if they exist at all.
|> (The 'object' above is a pointer to a union). This works
|> > everywhere except on m68k, where I can stop at a certain point in a
|> > debugger, and get different results for (*f)(a,b), and
|> > (object)(*(long (*)())f)(a,b), where f is declared object (*f)().
|>
|> Not quites sure form your code but I guess you hit the old function
|> return value thing.. what you are casting is not the function result
|> but the function declaration (changing result type in this case).
|> Could'nt you use the proper union-element instead of this cast?
|>
|> Function return values must be declared (and used) properly on m68k,
|> pointer values are returned in reg a0, ints d0. I would be surprised
|> if m68k was the only arch that gets broken by this..
Actually, this should not be a problem, because functions returning a
pointer put the return value in both registers, to support broken
programs. But nevertheless relying on this _is_ broken.
|> > I hate to have to work around this on all architectures just because
|> > of m68k, as was apparently done in earlier gcl versions. Is there a
|> > compiler switch, or function prototype declaration, or some other
|> > means whereby I can get the same results from the above two calls on
|> > this platform?
Always call a function as it was declared, everything else is calling for
trouble.
|> expecting 'long' result from pointer-returning functions would work
|> as long as you don't use -fomit-frame-pointer but is a horrible hack.
I don't think that -fomit-frame-pointer has any influence on this, but if
it does, then only by chance.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply to: