This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Macros, SCM and strict typing (cont'd)


Hello!

Just a few additional notes about achieving better type safety for guile:


gcc allows to cast to a union
-----------------------------

If a union contains a member of type x, gcc allows (as a GNU
extension) to cast a variable of type x to the union type.  This means,
that when defining SCM as union { scm_bits_t n; }, then the following will
work:   
    scm_bits_t x;
    SCM y;
    y = (SCM)x;
This is a problem, since there currently are places, where casts to SCM
values occur, which should be replaced by calls to SCM_PACK.

The only way that I know of to switch off this GNU extension is to use
-pedantic as a compiler option, but this reports a lot of other non-ANSI
things as well.

Does anybody know if there is an option to switch off single GNU
extensions, especially the 'cast to union' extension?

Until we know about such an option, a workaround is to define SCM as 
union { struct { scm_bits_t n; } n; } and change the definitions of pack
and unpack accordingly.


unions can not be compared
--------------------------

When defining SCM as a union (or a struct, I think) it is not possible any
more to compare SCM values with == or !=.

The question is:  do we want guile to compile cleanly, no matter how SCM
is defined, or do we treat the SCM-is-union case just as a means for
debugging?  In the latter case, there is no need to provide a solution, we
just accept the resulting compiler errors.  The disadvantage is, that implicit
tests of a SCM value agains zero are also reported as if an != operator had
been used:
    SCM x;
    SCM y;
    ...
    if (x != y) ...
    if (x) ...
are both reported as 'invalid operands to binary !=', which means that to
detect this kind of serious bugs, one has to check every single 'invalid
operands to binary !=' error message.

The other solution (having guile compile cleanly, no matter how SCM is
defined) implies, that basically no operation except assignment can be
expected to work with SCM values.  Thus, we have to agree about whether we
really want this conceptual change.  (I'm for this change, but others might
think differently.)

If so, I suggest the following patch to tags.h, which provides the SCM_EQ_P
predicate macro to compare different SCM values as with eq?, which is what
comparing SCM values with == is about.  (no line number for the patch, since
my local version differs a lot.)

diff -u -r1.42 tags.h
--- tags.h	2000/03/12 18:29:39	1.42
+++ tags.h	2000/03/14 03:37:22
 #define SCM_UNPACK_CAR(x) SCM_UNPACK (SCM_CAR (x))
 
 
+#define SCM_EQ_P(x,y) (SCM_UNPACK (x) == SCM_UNPACK (y))
+
+
 /* Cray machines have pointers that are incremented once for each word,
  * rather than each byte, the 3 most significant bits encode the byte
  * within the word.  The following macros deal with this by storing the


SCM values as case labels
-------------------------

Union variables, even if they are constant, can not be used as case labels.
The consequence is, that if we want guile to compile cleanly even in the
SCM-is-union case, all case labels that use SCM values have to use scm_bits_t
values instead.


to be continued...
Dirk Herrmann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]