Strung Out

[cottrell at nbs-vms.ARPA]

/*
> In DEC C, string constants are read-only.  They are in a special, write-
> protected psect.  If you try to do something like the above, you will
> get a run-time error.  --  Jeff Lichtman

My VAX-11 C V1.0 (5/82) manual says on page 235 sect 10.1.2 that char 
string constants are stored in a psect called "$CHAR_STRING_CONSTANTS"
(typical DEC verbose name, yawn) with the same attributes as "$DATA",
the psect where you can write to your hearts content. As proof:

main()
{	printf(strcpy("now you see it, now","YOU DON'T!\n"));
}

prints, "YOU DON'T\n". The storage map shows the strings as writable.

> The latest draft proposed ANSI standard for C supports a "const"
> type-modifier, to flag data that may not be modified.  String
> literals are (const char) arrays and may not be modified.  It
> is possible to initialize a non-const (char) array with a string
> if one wants to be able to modify it at run-time.

I have mixed feelings about this, but I can see why they did it.
No more `mktemp("/tmp/fooXXX");' Oh well, they never allowed
`int *p = &5;' either. Fingers, get moving!

> One significant advantage of (const char) strings is that they
> are ROMable.  Another is that storage for identical strings can
> be shared if the compiler/loader is sufficiently clever.

The compiler, yes. But I don't want the loader to have to compare
the contents of all my string psects char by char. Even a hashing
scheme would have to resort to this every once in awhile. Now, to
REALLY get `efficient', the loader could check for strings that
were trailing substrings of each other (address & dress :-)

	jim		cottrell at nbs
*/