Re: The relationship between SCM and scm_t_bits.

[prj@po.cwru.edu (Paul Jarc)]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> wrote:
> This is highly academic. Within guile there are so many places where
> we perform operations that are not defined according to the C
> standard: conservative garbage collection, copying stacks for
> continuations, assembly code, ...

Well, my impression is that Marius wants to get rid of at least this
particular bit of nonconformance.  Marius?

> Please explain, why you think that it is cleaner to say it only holds
> scheme objects if in fact it does not.

That's not exactly it.  The words that hold Scheme values would be
accessed using the SCM type, instead of coneverting to/from
scm_t_bits.  Other words, holding non-Scheme values, would still be
accessed as scm_t_bits.  (AIUI.)

> The standard says that the result of casting pointers to scm_t_bits
> to pointers to SCM gives implementation dependent results, right? Or
> does the standard explicitly forbid such casts?

Casting the pointer is ok in itself (well, unless there is an
alignment mismatch).  Accessing the pointed-to memory gives undefined
behvaior if there isn't actually an object there of the type you're
using to access it.

If SCM were defined as a struct containing scm_t_bits, then it would
certainly be legal to access an SCM object via scm_t_bits*.

> What is the reason to change a paradigm, which has for several
> years worked quite nicely, is easily understood, and has helped to
> find and probably also to avoid a bunch of errors? Is there any
> _real_ reason that any of you is facing, like that guile does not
> compile or work on one of your machines?

I think Marius is worried that there may be systems where the bits of
an SCM value are different from the bits of the corresponding
scm_t_bits value.  I don't know whether any have actually been found.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel