Richard Zidlicky <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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."
