Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!husc6!ut-sally!utah-cs!defun.utah.edu!shebs
From: shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp lacks portability
Keywords: Common Lisp
Message-ID: <5173X@utah-cs.UUCP>
Date: 21 Jan 88 00:00:00 GMT
References: <1421@orstcs.CS.ORST.EDU> <233@spt.entity.com> <2126@ulowell.cs.ulowell.edu>
Sender: news@utah-cs.UUCP
Reply-To: shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 26

In article <2126@ulowell.cs.ulowell.edu> ross@swan.cs.ulowell.edu (Ross Miller) writes:

>[...] By accident he sends a float to polyline when an integer
>was expected.  Lisp then passes the 32bit word down to say C, machine size
>may vary, and C blithly trys to write out a few million polylines, or some
>other random number or worse a negative array reference, and the OS 
>informs us of an array overflow. [...]

If anybody is surprised by all this, mail me and I'll send you a catalog
of palaces in England I've been handling.

There has been talk of doing "safe" interfaces between Lisp and C, but as
long as I can do *(12345) in the address space of my Lisp system, nothing
is safe.  I can get a little help by using an interface that checks types,
but it's going to be a dog, no way around it.

>	On another subject have I missed the argument on why arrays are not 
>always passed by value?

Oh yeah, I like making copies of million-byte arrays every time I pass them
to a function.  Just think, I would get a copy with every call to AREF!
That would show those purely functional weenies what *real* storage allocation
is like!  :-) :-)

							stan shebs
							shebs@cs.utah.edu