Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!munnari!bruce!goanna!yabbie!rcodi From: rcodi@yabbie.rmit.oz (Ian Donaldson) Newsgroups: comp.unix.wizards Subject: Read-only literal strings (was Re: Problem with xstr) Message-ID: <870@yabbie.rmit.oz> Date: 21 Sep 88 03:35:38 GMT References: <145@taux02.UUCP> Organization: RMIT Comm & Elec Eng, Melbourne, Australia. Lines: 28 From article <145@taux02.UUCP>, by amos@taux02.UUCP (Amos Shapir): > Xstr is a hack for putting strings, which are supposed to be read-only, > into the executable's text (code) space. This makes more room for data > on machines with limited address space. On 32-bit machines, this > approach is obsolete and causes more trouble than benefit. A side affect that Amos omitted is that the strings are shared amongst all simultaneous invication of the program, thus reducing memory requirements in the machine. The approach will never be obsolete, but as memory is getting cheaper... Anyway, my question is, why *does* the C compiler put literal strings into the data segment? Surely literal strings are considered constants just like 123, 45.34e44, so they should be unchangeable at run-time. Many programs run quite happily with read-only strings, but a few as I have discovered, don't eg: ucb sendmail. This is because it passes a literal string to a routine that expects a buffer it can write in. The result is that the original string gets clobbered and the next invocation of the routine by the caller produces wierd (perhaps intended ?) results. I rekon that the C compiler should put strings into the text by *default*, and have a switch so that porting ugly programs is easier if you really can't be bothered fixing somebody else's broken code (like me). xstr could be eliminated completely then! Ian D