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