[Top][All Lists]

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

Re: [Gcl-devel] Re: (object (*)()) vs (long (*)())

From: Camm Maguire
Subject: Re: [Gcl-devel] Re: (object (*)()) vs (long (*)())
Date: 02 Aug 2002 18:38:46 -0400


Richard Zidlicky <address@hidden> writes:

> On Thu, Aug 01, 2002 at 03:08:00PM -0400, Camm Maguire wrote:
> > Greetings, and thanks for your *very helpful* reply!
> > 
> > OK, now it is clear to me what is going on.  I calling all functions
> > through a variable declared to return a pointer, and some functions
> > are returning a long.
> > 
> > I can fix the instances in the existing code fairly easily, but the
> > issue is that the lisp compiler produces C code using these
> > interchangeable declarations.  At some point, I need to either have
> > all compiled functions return the same union and use the existing
> > function link helper functions (in funlink.c, et.al.), or to duplicate
> > these functions to handle function variables returning long and modify
> > the compiler to use these in the correct instances instead.  As
> > always, the implementation is much easier than the conception of the
> > proper solution.  Comments most welcome.
> imo the proper thing for lisp-like systems is to return some opaque 
> long or union type for all functions. The caller mostly has to check
> the return type of the result which involves some bit-fiddling so
> a long is pretty convenient.
> Only in places where the compiler is good enough to infere *all* type 
> information you could use native 'c' types, but those are the cases 
> that can be easilly inlined and the compiler has enough information 
> to use correct functin declaration I would assume.

Gcl does this in part.  The caller can distinguish the actual function
return type from an opaque call via some 'bit fiddling'.  But the
actual function declarations were in terms of native C types.  I
believe I've fixed this now.  We'll see with the Debian autobuilders!
:-). (Maybe I'll get lucky and my sole remaining problems on hppa will
be solved?)

> I haven't looked into the gcl sources yet, but scm/hobbit is an example 
> how to get such things pretty portable, the bit-fiddling it uses looks 
> pretty wild but appears really stable and portbale.

Thanks for the pointer!

> Alternatively you could define your own name-mangling/signature
> control a'la c++ and have lots of fun with it :)

Uh, I'll pass thanks!

> > Alternatively, I could leave everything the way it is if I could
> > insert assembly copying the long destination register to the pointer
> > destination register at each function close, but this does not sound
> > likely. 
> it seems that before doing that kind of effort it would be much easier
> to fix the compiler to generate consistent code?

OK, it wasn't as hard as I thought.  But all I did was what appeared to
be a minimal change to correct all casting problems reported by gcc
-Wall.  Some unnecessary casts have been introduced, but should be
harmless.  I hate casts, as they frequently prevent gcc from catching

Take care,

> Richard

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]