Re: Name change: SCMWORD --> scm_word_t

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> >   SCM_UNPACK (x)
> >   SCM_UNPACK_CAR (x)
> >   SCM_PACK (x)
> 
> Actually, I settled for this.  (You may of course protest! :)
> 
> The reason is that this is clearer and more symmetric: It's easy and
> feels good to explain in the reference manual that SCM values are
> normally "packed" and that you have to "unpack" them in order to
> access the bit structure.

I've included the NEWS entry below.  Note that SCM_UNPACK is more
neutral to the use of the value than SCM_BITS.  It is more compatible
with both uses where you're dealing with bitfields and uses where you
want to treat the SCM value as an integer.

** New macros: SCM_PACK, SCM_UNPACK, SCM_UNPACK_CAR

Compose/decompose an SCM value.

The SCM type is now defined as void * on most architectures.  This
makes it easier to find several types of bugs, for example when SCM
values are treated as integers without conversion.  Values of the SCM
type should be treated as "atomic" values.  These macros are used when
composing/decomposing an SCM value, either because you want to access
individual bits, or because you want to treat it as an integer value.

E.g., in order to set bit 7 in an SCM value x, use the expression

  SCM_PACK (SCM_UNPACK (x) | 0x80)

SCM_UNPACK_CAR (X) is defined as SCM_UNPACK (SCM_CAR (X))