[net.unix-wizards] pcc shared string question

dan@msdc.UUCP (07/25/84)

I have a family of libraries that have bunches of embedded
double-quoted strings (about 30KB or so).  What I want to do is arrange
to put all the strings in shared text space (we're running 4.Xbsd on
VAXen).  Since the "xstr" stuff is cumbersome with this much code, what
I think I want is something on the order of the "-R" assembler option
for just initialized strings.

After perusing the "pcc" code, and examining reams of assembly output,
it seems to me that double-quoted strings are output into data segments
1 and 2, while static data declarations go in segment 0.  Thus, it
looks like I can add an option to "ccom" (and "cc") that affects only
the STRNG and ISTRNG cases in "locctr()".  When set, it causes the
generation of ".text 1" and ".text 2" in place of ".data 1" and ".data
2" respectively.  (I could also do this with the old "asm.sed" trick,
but I don't think I want to rewrite all the Makefiles.)

My question is thus directed at all the "pcc" wizards out there:  None
of the libraries ever modify double-quoted literals, but they do modify
static data (which should still appear under data segment 0).  I'm not
all that concerned about portability, since on other machines all that
will happen is that the programs will get bigger again.  So, what kind
of trouble am I buying here?  What have I missed?

Dan Forsyth  (akgua!gatech!msdc!dan, duke!mcnc!msdc!dan)
Medical Systems Development Corporation, Atlanta, GA

greg@sdcsvax.UUCP (07/26/84)

In article <106@msdc.UUCP> dan@msdc.UUCP (Dan Forsyth) writes:
>None of the libraries ever modify double-quoted literals ....  So,
>what kind of trouble am I buying here?  What have I missed?

Close.  The original implementation of our compiler put double-quoted
strings in text space and we got along just fine for months.  However,
although nowhere in the LIBRARIES are double-quoted literals modified,
at least one UTILITY does.  The offending utility is "ed" which has:
    tfname = mktemp("/tmp/eXXXXXX");
in it.  Mktemp() blissfully stomps on the string passed to it, so this
will modify the literal.  I'd argue that this is bad coding practice,
but in the end, we put our strings in the data segment to be compatible
with the rest of the C community.  (My feeling is that literals should
be literal (i.e., mean what they say) and thus should NOT be modifyable.)

Other than dangers like that, you should be perfectly safe in putting
your strings in the text area.  I'd be curious to know if you encounter
any other problems.

Does anybody know what the proposed C standard has to say on the subject?
I'd be willing to propose that literals (as opposed to initializers) be
read-only by default, as if they had the "const" attribute.  Anybody have
any other thoughts on the subject?
-- 
-- Greg Noel, NCR Torrey Pines       Greg@sdcsvax.UUCP or Greg@nosc.ARPA

bob@SU-SHASTA.ARPA (07/30/84)

Even if library routines do not modify string literals and mktemp() copies
its parameter to malloc'ed data space, programs routinely modify literals
supplied by library routines.

I know that this is bad practice but why fight reality. Even login core dumps
when you take away address zero (in System V on a m68000).

Bob Toxen
Silicon Graphics
ucbvax!Shasta!olympus!bob