[Gcl-devel] Re: Harper

[Camm Maguire]

Greetings!

"Gordon Shaw Novak" <address@hidden> writes:

> It is clear that these function prototypes were kludged in by
> declaring everything to be 'int'.  At one point, I went in and
> did some editing just to get rid of a lot of C warnings of
> "assigning integer to pointer without a cast".
> 
> The protorypes are defined now by defentry's in gcl_Xlib.lsp .
> I guess I'm not clear on how those trade off with Camm's new
> xgcl.h : do functions need to be defined in both, either, or
> is there a best way to do it?
> 

Thank you so much for mentioning this -- I had never thought of the
defentry as a prototype mechanism.  With a small change to t3defentry,
I can have the compiler put in a corresponding prototype
automatically.   This should obviate xgcl.h

We still have the basic issue that we are fooling the C compiler into
doing a silent integer to pointer cast.  If we add a void* defentry
type, perhaps the alternative would be to include the Xlib.h headers
-- at least then we could catch future incompatible changes in xlib at
compile time.  The basic problem is that we cannot follow every C
struct with separate support in defentry, and any attempt to collapse
all calls onto a pre-defined set of C primitives will foil prototype
checking to some extent -- i.e. passing a void * to a function
expecting to write a certain amount of data will compile but might
silently lead to a memory overwrite.  So the basic decision is whether
there is enough value in prototype checking with a finite set of
pre-defined C primitives, or whether we should just assume the
defentry writer knows exactly what they are doing and ensure that the
compiler not complain and leave any errors to run-time failure.

Thoughts on this are most appreciated.  In the mean time I will try
the simple "follow defentry for prototyping" idea and at least see if
all the wtests pass.

> I am willing to work on filling these in.  It seems better to
> do it right rather than just doing another kludge.
> 

Thank you!

> Note that the 'easy-to-use' interface dwindow.lsp / dwtrans.lsp
> only uses a fraction of the huge Xlib.  We could probably make
> dwindow.lsp work with just a half-dozen prototypes.  Even the
> full set of symbols in XLIB: may be less than the size of the Xlib.
> 

Interesting -- so xlib might provide wider possibilities for some
hypothetical user, yes?

> Camm, if you can give me an example or two of how it should be
> done, I can go ahead and edit the files.
> 

I'll be happy to do so, but this will depend on what we decide above. 

> There are some other C files that may need to be changed, e.g.
> XStruct-4.c calls calloc() and returns the result as (int)
> whereas on a 64-bit machine probably any calloc() should be
> assumed to be 64 bits.
> 

Thanks!  Any direct edits you care to make here are fine and
independent of the discussion above.  In general, you can count on gcl
defining fixnum to be the machine wordsize and equivalent to the size
of a pointer.  On all machines of which I am aware, this is also
'long'. 

Take care,

> Harper seems to be going down quite often today.
> 
> Best regards, Gordon
> 
> 
> 

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