🚀 go-pugleaf

In article <5812@batcomputer.tn.cornell.edu>, davidra@batcomputer (David A. Rabson) writes:
] I just got my hands on a copy of the second edition of K&R and was
] 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.

The GNU C compiler does not allow the programmer to modify string constants.
This feature can be turned off.

Dan Schmidt
dschmidt@athena.mit.edu

In article <5812@batcomputer.tn.cornell.edu>
davidra@batcomputer.tn.cornell.edu (David A. Rabson) writes:
>... second edition of K&R ... "[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.

On the contrary, in practise it causes very little to break.  Mktemp()
is in fact the only place I have seen code crash.  Callers will have
to write

	static char foo[] = "/tmp/abcXXXXXX";
	name = mktemp(foo);

rather than simply

	name = mktemp("/tmp/abcXXXXXX");

This is inconvenient, but not, I think, too drastic.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

In article <5812@batcomputer.tn.cornell.edu> davidra@batcomputer.tn.cornell.edu (David A. Rabson) writes:
>I just got my hands on a copy of the second edition of K&R and was
>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.

It only causes certain uses of mktemp to break.  You can no longer say

	name = mktemp ("/tmp/fileXXXXXX");

but you can say

	char template[] = "/tmp/fileXXXXXX", *name;
	name = mktemp (template);

I know of no other code I've ever written that this change would break.
But then, I do a lot of C code for standalone applications (C in ROM,
with a minimal real-time OS) and in the compiler I use for that, strings
go in a separate section and I put that section in ROM.

There's also the Berkeley xstr hack, for collecting commonly used strings
and compressing.  This will only work if you don't attempt to modify strings.
-- 
- Joe Buck  {uunet,ucbvax,pyramid,<smart-site>}!epimass.epi.com!jbuck
jbuck@epimass.epi.com	Old Arpa mailers: jbuck%epimass.epi.com@uunet.uu.net
	If you leave your fate in the hands of the gods, don't be 
	surprised if they have a few grins at your expense.	- Tom Robbins

In article <5812@batcomputer.tn.cornell.edu> davidra@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@zoo.toronto.edu