[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue CONSTANT-MODIFICATION, version 2
- To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Subject: Re: Issue CONSTANT-MODIFICATION, version 2
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 12 Jan 89 10:38:27 CST
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Msg of Tue, 10 Jan 89 00:39:18 GMT from Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Sender: GRAY@Kelvin.csc.ti.com
> But why can't constants be modified in compiled code? It seems clear
> that they could be, so there must be some reasons why they aren't
> always modifiable, and those are the real reasons.
Besides the considerations of current practice and consistency, there's another
point that should be added to the rationale: modification of constants is a
dangerous and error-prone thing to do. Since our object file loader places
constants in write-protected memory, I have received many complaints from users
who think they have found a bug because they get an error on a store, but when
I talk to them about what they are doing, in nearly every case it turns out
that the modification they were prevented from doing was not really what they
wanted to do anyway. I can recall only two cases where users understood the
consequences of modifying a constant and had a legitimate reason for doing so;
for them, the LOAD-TIME-VALUE form provides a way to get a modifiable value.
For example, a naive programmer might write something like
(defun hack (n)
(let ((string "........."))
(setf (char string n) #\X)
(write-string string)))
which works as expected only the first time it is called. This is a common
mistake for programmers with previous experience in languages such as Pascal
where a string assignment copies the string.