Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!cottrell@nbs-vms.ARPA
From: cottrell@nbs-vms.ARPA
Newsgroups: net.lang.c
Subject: Strung Out
Message-ID: <8997@brl-tgr.ARPA>
Date: Wed, 6-Mar-85 12:00:05 EST
Article-I.D.: brl-tgr.8997
Posted: Wed Mar  6 12:00:05 1985
Date-Received: Fri, 8-Mar-85 03:41:45 EST
Sender: news@brl-tgr.ARPA
Lines: 38

/*
> 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@nbs
*/