[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The relationship between SCM and scm_t_bits.

From: Paul Jarc
Subject: Re: The relationship between SCM and scm_t_bits.
Date: Sun, 23 May 2004 11:03:41 -0400
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)

Dirk Herrmann <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]