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]

Re: Again: compile time debug mode


On 28 Nov 1999, Ken Raeburn wrote:

> Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> > What about applying some patch like below, which was taken from a mail
> > from Ken Raeburn?  In the beginning this patch does not inhibit any
> > compilation, but allows for smoothly changing guile's source in a way that
> > it will finally be possible to compile with GUILE_COMPILE_TIME_DEBUG_MODE
> > defined.
> 
> Under many configurations, returning (and occasionally passing) a
> union is done by reference, so that change would be bad for
> performance.  It would also be an incompatible change; an application
> built with header files using the union would not be able to call a
> pre-built shared library built using the integral type.

The macro GUILE_COMPILE_TIME_DEBUG_MODE would only be set for compilation,
but never to run the resulting executable.  After that, when the code is
compiled without defining GUILE_COMPILE_TIME_DEBUG_MODE, the code is the
same as ever before.  Thus, it is _not_ an incompatible change.

> The better idea we've come up with is to use gcc's transparent union,
> once some fixes get into the compiler to make it apply properly to
> return values.  (I'm supposed to be working on those compiler patches,
> but no progress yet.  Gotta bug the boss again about paperwork.)
> Then, when a recent enough gcc is used, an efficient and compatible
> calling sequence will be used, with the avoidance of type confusion;
> when gcc is not used, or too old a version is used, the integral type
> will be used, keeping the performance and losing the type checks.

I understand that, but the point is, that the change that I have suggested
will allow _today_

1) to prepare guile for the time when the union solution as soon as it is
available.  Doing this, certain errors within guile might show where SCM
and long values are mixed up.

2) to check user code for such mixups.

Both, 1) and 2) would have to be done at the time the gcc patch is
available anyway. The only difference that I can see between doing it
today and doing it later would be whether you would like to avoid the use
of a SCM_BITS (or similar) macro in the latter case.  If this was the
case, 1) could not be done in the right way today, because you would like
to write x.u instead of SCM_BITS(x) throughout guile.

However, it may make sense to always use a macro to access the data behind
a SCM value since this allows to distinguish between a fast compilation
mode and a compile time error check mode for compilers other than gcc.

The way it is today does not allow anybody to provide patches to make
guile more type safe, even if they liked to do so.  So, please, decide
about the way SCM values are to be handled as soon as the gcc patch would
be available.  If you decide for the SCM_BITS (or similar) macro style,
the patch I sent does not introduce any incompatibilities but rather
allows to improve guile's type safety today.

Dirk Herrmann


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