0.9.13.16: preliminary Windows installer builder

[sbcl.git] / src / code / target-c-call.lisp

diff --git a/src/code/target-c-call.lisp b/src/code/target-c-call.lisp
index 2d21d6d..df7fa8c 100644 (file)
--- a/src/code/target-c-call.lisp
+++ b/src/code/target-c-call.lisp
@@ -23,11 +23,13 @@
 (define-alien-type short (integer 16))
 (define-alien-type int (integer 32))
 (define-alien-type long (integer #.sb!vm::n-machine-word-bits))
+(define-alien-type long-long (integer 64))
 
 (define-alien-type unsigned-char (unsigned 8))
 (define-alien-type unsigned-short (unsigned 16))
 (define-alien-type unsigned-int (unsigned 32))
 (define-alien-type unsigned-long (unsigned #.sb!vm::n-machine-word-bits))
+(define-alien-type unsigned-long-long (unsigned 64))
 
 (define-alien-type float single-float)
 (define-alien-type double double-float)
@@ -39,6 +41,11 @@
 ;;; appear to be vulnerable to the lisp string moving from underneath
 ;;; them if the world undergoes a GC, possibly triggered by another
 ;;; thread.  Ugh.
+;;;
+;;; Actually the above shouldn't happen; x86 and x86-64 use GENCGC,
+;;; so the string can't move by virtue of pointers to it from
+;;; outside the heap. Other platforms will access the lisp string
+;;; through the GC-safe interior pointer. -- JES, 2006-01-13
 (defun %naturalize-c-string (sap)
   (declare (type system-area-pointer sap))
   (locally