my two cents (string constants, trigraphs)

[Henry Spencer]

In article <5812 at batcomputer.tn.cornell.edu> davidra at batcomputer.tn.cornell.edu (David A. Rabson) writes:
>...distressed to read that "[string constants] are no longer modifiable,
>and so may be placed in read-only memory."
>
>This will cause mktemp() and many, many other things to break.  I hope
>the committee will reconsider this: if it stays in the standard,
>people who write compilers are going to have to add a compiler option
>to turn it off.  More likely, they will keep it off by default.

No, actually, many people who write compilers have been waiting for something
like this for a long time, so they could put strings in read-only data.
(Both to put them in EPROM for controller applications and to put them in
shared [doesn't have to be copied on every fork()] space in Unix.)  As far
as I know, sloppy use of mktemp() is the *only* thing that will break...
and many of us have considered using mktemp() to modify a string literal
to be bad practice all along.

>The purpose of trigraphs is only slightly less opaque...  Trigraphs,
>too, could cause programs to break, although not so many as the
>string-constant nonsense.

The purpose of trigraphs is to make it possible to write C code using only
the nationality-independent parts of the ISO 7-bit character set (ASCII
being the national version of same that applies in the US and Canada).
The desirability of this is debatable, especially since the problem is better
solved by using the ISO Latin 8-bit character set, but let's not get into
that argument again!  Very few current programs actually use the sequences
of characters that form trigraphs (note that trigraphs are *not* an open-
ended set, the ones given in the X3J11 drafts are explicitly the only ones),
so there is not much of a compatibility problem here.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry at zoo.toronto.edu