Re: Namestring&pathstring returning shared structure

[NGALL@G.BBN.COM]

    Date: Sat, 21 Jun 1986  12:41 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   masinter.PARC@XEROX.COM
    Subject: Namestring&pathstring returning shared structure
    Message-ID: <FAHLMAN.12216617014.BABYL@C.CS.CMU.EDU>
    
    
    Signaling an error or doing a copy when someone destructively modifies
    the string for a symbol's name is a pain.  If there's a problem here, we
    should simply make sure the user never gets his hands on such a string
    by copying on the way in and copying again on the way out.  However, I'm
    not convinced that there's a problem here, except that the manual does
    not state clearly enough that this string is shared, registered in a
    hash table, and should not be messed with.  Are people really in danger
    of screwing themselves here?
    
    -- Scott
    
	      --------------------
		
I agree that all that is needed is more clarity in the manual as to
which functions are guaranteed to return unshared structures, which
functions return shared structures, and which functions for which the
sharability of the object returned is undefined.

I think I may have misled people into thinking that I was only worried
about the interaction of pathnames and symbol-names.  I was just using
it as an example on implicit sharing (one that caused me a lot of
grief in porting to KCL).  But there are many other examples of
possible character sharing between strings (e.g., string-trim,
parse-namestring, package-name, intern, etc.).  Implementations such
as KCL, which use separate string headers and bodies (which are just
raw sequences of chars.) will typically just create a new string
header which points into an existing string body whenever possible.
Unless the user knows when to be on the alert for this, s/he will
eventually come to grief.

	-- Nick