[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: Dirk Herrmann
Subject: Re: The relationship between SCM and scm_t_bits.
Date: Sat, 22 May 2004 08:48:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220

Paul Jarc wrote:

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

reply via email to

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