Quoting Anton Kovalenko (anton@...):
> * A harmless and important step towards Windows/x64 platform support
> - During all my time dedicated to SBCL, there was a single instance of
> an experience that I'd like to never meet again. 64-bit Windows
> defines "long" type as _not_ being pointer-sized; and SBCL,
> especially in parts written in C, relies on "long" and "unsigned
> long" being pointer-sized in countless places.
> Before the real work required for x64 Windows support, I had to walk
> through almost every C source, adjusting type declarations -- almost
> mechanically but not entirely mechanically (or else it would be
> scriptable). Most of these places in my SBCL tree now have either
> * intptr_t (or uintptr_t) -- where I perceived the primary intent of
> code authors to have a "pointer-sized" value, and
> * sword_t (uword_t), that are my own typedefs -- where I recognized
> an intent to have a "machine-word-sized" value, with no explicit
> connection to pointers.
thanks. I'm going to push large parts of these hunks rather soon, and
in only slightly modified form.
> Unfortunately, I don't have enough knowledge of all platforms that
> SBCL is targetting (specifically, I've never programmed Alpha); so
> while there are many typedefs in SBCL that seemed appropriate for
> pointer-sized values, I wasn't too sure that they are good in this
> role for other platforms. That's what caused me to introduce new
> typedefs, which are better to be understood as synonyms for
> "long and unsigned long on non-braindamaged systems".
Here's the plan: The changes will be split up into several commits, one
for each type being replaced, allowing easy review by other developers.
`signed long' will (usually) be turned into sword_t, and
`unsigned long' will (usually) be turned into uword_t.
However, uintptr_t will not be used much explicitly -- this is a
deviation from the windows branch. The hunks which had introduced the
uintptr_t/uword_t differentiation will instead be search&replaced into
using uword_t consistently. The distinction between the two kinds of
uses does not seem clear-cut enough to me to warrant having developers
think about which one to choose. (Similar thoughts apply to a few other
places using alternative names for these types.)
Finally, lispobj (I think this is the only real feedback from earlier
discussions) is generally considered to serve a different purpose, even
though it is (technically) the same as uword_t.