rcodi@yabbie.rmit.oz (Ian Donaldson) (09/21/88)
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
gwyn@smoke.ARPA (Doug Gwyn ) (09/23/88)
In article <870@yabbie.rmit.oz> rcodi@yabbie.rmit.oz (Ian Donaldson) writes: >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 use mktemp() with a string literal argument. This is now considered nonportable, but why cause problems for those programs by changing the rules unnecessarily? >I rekon that the C compiler should put strings into the text >by *default*, ... No, it should perhaps put strings in a read-only data segment (or better yet, a shared literal pool). This is permitted by the proposed ANSI C standard. People should start fixing their code NOW.
krohn@u1100a.UUCP (Eric Krohn) (09/27/88)
In article <870@yabbie.rmit.oz> rcodi@yabbie.rmit.oz (Ian Donaldson) writes:
] 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.
On Unisys' flavor of SVR2 (called SX 1100), I tried the readonly strings
option when building ksh, and found that ksh got very upset. It turned out
that one of the strings placed into the text segment was "." and when ksh
passed that to stat(2) in determining the current directory, the SX kernel
said EFAULT. Namei checked to make sure the string was a legal *data* address.
Since SX 1100 only (!) provides 500KBytes of data space, I was quite interested
in conserving data space.
Moral: It's not just ill-behaved user programs that dislike this method of
obtaining readonly strings.
--
--
Eric J. Krohn
krohn@ctt.ctt.bellcore.com or {bcr,bellcore}!u1100a!krohn
Bell Communications Research, 444 Hoes Ln, Piscataway, NJ 08854