Greetings! "Gordon Shaw Novak" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
