Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uwmcsd1!marque!lakesys!chad From: chad@lakesys.UUCP (D. Chadwick Gibbons) Newsgroups: comp.lang.c Subject: modification of strings Summary: modification of string constants in string functions Keywords: string, constants, pointers Message-ID: <345@lakesys.UUCP> Date: 3 Feb 89 22:29:43 GMT Reply-To: chad@lakesys.UUCP (D. Chadwick Gibbons) Distribution: usa Organization: Lake Systems - Milwaukee, Wisconsin Lines: 40 I believe my understanding is mislead when it comes to the interpretation of string constants and the effect the standard library functions can preform on them. Insofar as I have been told, strings can not be modified - note, the type char *blah = "this is a string"; not the everyday normal strings we use. This would appear that if you attempted to modify their contents, you would either get a core dump of some various flavor, or the program would ignore your request. In general, the function of strcat is defined as char *strcat(s, ct) char *s, *ct; Where s is the original string you wish to add too, and ct is the string you wish to append - as I'm sure you really didn't know that :) With that definition, consider the following artificial sequence char *blah = "meow"; char *tmp; tmp = strcpy(blah, "grr, snarl, hiss"); I would think since the string 'blah' is considered to be nonmodifiable that it would not be changed, but the result would be placed into tmp. However, on different systems, this provides different results: SCO XENIX/286 2.2.2 core dumps on next access of anytype to 'blah' SCO XENIX/386 2.3.2 gives various warning messages but treats 'blah' like a normal string BSD 4.2 does random things AT&T System V r3 refuses to work on Thursdays, but acts like XENIX/386 on others Apparently, either the effect of strings is not yet defined in these implementations, or, more likely, what I was taught is incorrect. Enlightenment is welcomed. -- D. Chadwick Gibbons, chad@lakesys.lakesys.com, ...!uunet!marque!lakesys!chad