The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment	size?
Date: Sat, 28 Nov 2015 18:30:53 -0500	[thread overview]
Message-ID: <1448753456.23036.for-standards-violators@oclsc.org> (raw)

I'm too tired to dig for the exact words in the ISO standard,
but I had the impression that the official C rule these days
is that the effect of writing on a string literal is undefined.

So it's legal for an implementation to make strings read-only,
or to point several references to "What's the recipe today, Jim"
to one copy of the stripng in memory, and even to point uses of
"Jim" to the tail of the same string.  Or both.

It is also legal for every string literal to reside in its own
memory and to be writable, but since the effect is undefined,
code that relies on that is on thin ice, especially if meant to
be portable code.

I have used, and even fixed (unrelated) bugs in, a compiler
that merged identical strings.  I forget whether it also looked
for suffix matches.  Whether the strings went in read-only
memory was up to the code generator (of course); in the new
back-end I wrote for it, I made them so.  This turned up quite a
few fumbles in very-old UNIX code that assumed unique, writable
string literals, especially those that called mktemp(3).  To my
mind that just meant the programs needed to be fixed to match
current standards (just as many old programs needed fixes to
compile without error in ISO C), so I fixed them.

I didn't (and still don't) like Joy's heavy-handed hack, but I
see his point, and think it's just fine for the language rules
to allow the compiler to do it hacklessly.

Norman Wilson
Toronto ON



             reply	other threads:[~2015-11-28 23:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28 23:30 Norman Wilson [this message]
2015-11-28 23:38 ` Charles Anthony
2015-11-30  3:07   ` John Cowan
2015-11-30  5:38     ` Nick Downing
  -- strict thread matches above, loose matches on Subject: below --
2015-11-28 14:58 Doug McIlroy
2015-11-27 22:26 Larry McVoy
2015-11-27 23:44 ` Dave Horsfall
2015-11-28  0:03   ` Larry McVoy
2015-11-30  2:45     ` Erik E. Fair

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1448753456.23036.for-standards-violators@oclsc.org \
    --to=norman@oclsc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).