Re: The relationship between SCM and scm_t_bits.

[Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>]

Paul Jarc wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> wrote:
>
> > As long as it is just a cell, we check the bits. Only if we know
> > its a pair, we dare to access it as a pair of SCM values.
>
>  But according to the C standard, we shouldn't dare to access it as
>  scm_t_bits either. unsigned char is the only universally safe
>  aliasing access type.

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, ...

Certainly, the way we convert between scm_t_bits and SCM is
implementation dependent. However, the definitions for scm_t_bits
and SCM are IMO a very good way to provide an abstraction of
some of this uncleanlyness. And, with today's definitions of
scm_t_bits and SCM, the heap _must_ hold scm_t_bits variables.
Please explain, why you think that it is cleaner to say it only holds
scheme objects if in fact it does not.

I am still missing the background for the whole discussion: 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?

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?

Best regards
Dirk



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