1.0.27.37: fix host constant leaks
authorChristophe Rhodes <csr21@cantab.net>
Fri, 24 Apr 2009 13:11:22 +0000 (13:11 +0000)
committerChristophe Rhodes <csr21@cantab.net>
Fri, 24 Apr 2009 13:11:22 +0000 (13:11 +0000)
commit3e377a9a6da8d55835dd695c63defad84701ba40
treea8ea32b6cd5e428aa6bd56aa3dbc702774618c52
parent16062fad470533e429a12ac9cd0b9e53aa0e1e90
1.0.27.37: fix host constant leaks

Various ways in which a host constant can leak through the
cross-compiler into the target are plugged.

5 commit messages follow:

fix host most-positive-fixnum leak in declaration

Found by comparing object code for SORT-VECTOR between clisp and sbcl xc
hosts.

Fix most-fooative-fixnum leak in number-psxhash

Gah, floats.  Most cases will be more complicated to fix than this one.
(Fixing things absolutely properly would be hugely difficult; this fix
should do for now...)

more careful cross-compiler constant-form-value

We need to take values from the xc info database in preference to using
SYMBOL-VALUE, otherwise we'll leak from the host.  (In particular, this
one was for function in debug.lisp with lambda lists of the
form (&optional (n most-positive-fixnum))

deal with another host fixnum-related constant leak

This time it's in the definition of the integer constants which are both
fixnums and exactly representable as floats.  Amazingly, just above
these definitions are the ones for SB!XC:MOST-POSITIVE-FIXNUM and
friends; no alarm bells were ringing...

fix a fixnum leak in unix-fd type

This mistake [ (deftype foo () `(integer 0 ,most-positive-fixnum)) ]
seems distressingly easy to make.  Not easy to guard against, either.
(Aside: is it sensible to define FDs as positive fixnums?)
src/code/target-sxhash.lisp
src/code/unix.lisp
src/compiler/constantp.lisp
src/compiler/generic/early-vm.lisp
src/compiler/srctran.lisp
version.lisp-expr