Xref: utzoo comp.unix.aix:1017 comp.lang.c:28579
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!orcenl!bengsig
From: bengsig@oracle.nl (Bjorn Engsig)
Newsgroups: comp.unix.aix,comp.lang.c
Subject: Constant strings (Was: Re: what does 9013 have that 9005 lacks)
Message-ID: <875@nlsun1.oracle.nl>
Date: 9 May 90 08:37:36 GMT
References: <1990May7.172832.11722@edm.uucp> <5308@ibmpa.UUCP>
Reply-To: bengsig@oracle.nl (Bjorn Engsig)
Followup-To: comp.lang.c
Organization: Oracle Europe, The Netherlands
Lines: 28

I'm sorry, but it is not correct when steve@qe2.UUCP (Steve DeJarnett) says:
  [as a followup to why char *dummy="string"; dummy[0]='S'; segm violates]
|If you want to get around this, 
|change the definition/declaration from char *dummy="string" to 
|char dummy[]="string".  Not much difference, but just enough for ANSI.
As I pointed out in another followup, constant strings should not be
modified according to ANSI.  The precise wording in K&R2 (A2.6) is that the
behaviour of modifying a string literal is implementation defined. 

char *dummy1  = "string1";
char dummy2[] = "string2";

dummy1[0] = 'S';	/* violates ANSI by trying to change 's' in "string1" */
dummy2[1] = 'T';	/* violates as well trying to chage 't' in "string2"  */

dummy1 = "new1";	/* is OK, since it changes the char pointer dummy1, but
			   after doing it, the string "string1" cannot be
			   accessed any longer using dummy1 */

strcpy(dummy2,"new2");	/* violates, since you try to overwrite "string2" */

The xlc compiler for AIX 3.1 can be given the option -qnoro to put string
literals into the data-segment, and then they can be modified.

Please continue this discussion in comp.lang.c if necessary.
-- 
Bjorn Engsig,	Domain:		bengsig@oracle.nl, bengsig@oracle.com
		Path:		uunet!mcsun!orcenl!bengsig