davidra@batcomputer.tn.cornell.edu (David A. Rabson) (08/08/88)
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 purpose of trigraphs is only slightly less opaque. I remember there was a discussion of them a few weeks ago, but I read only a part of it. I missed any justification for them. Can anyone name a computer or operating system that requires trigraphs? Trigraphs, too, could cause programs to break, although not so many as the string-constant nonsense. I imagine that my complaints at this point are likely to be ignored by the standards committee, but I hope someone at Sun or AT&T is listening. David Rabson davidra@helios.tn.cornell.edu
dschmidt@athena.mit.edu (Dan Schmidt) (08/08/88)
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.educhris@mimsy.UUCP (Chris Torek) (08/08/88)
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
jbuck@epimass.EPI.COM (Joe Buck) (08/08/88)
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
henry@utzoo.uucp (Henry Spencer) (08/09/88)
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