T
Tim Rentsch
Keith Thompson said:
Certainly a lot of it has. But it would be nice to have
a choice, especially since the problems may manifest more
subtly than having code blow up (eg, overlapping different
string literals in writable memory).
Sure, but an option to have literals be writable gets both.
If I were writing a compiler I'd rather have to provide
only one option rather than two.
Me either, but then I tend to use debuggers in rather
simple ways, and I know there are developers for whom
the exploratory capabilities of their debuggers is
quite valuable.
Some developers would benefit from such a guarantee. Most
developers already have the benefit available to them.
Oh, the other compiler doesn't have to be used to produce the
object files; it can be used _in addition to_ the particular
target compiler, just to provide extra error checking. Granted,
there can be discrepancies between the two compilations if there
is platform-specific conditional compilation, but programs that
make extensive use of that have much deeper problems than string
literals.
To say this another way - can you name one real-world example
of a program where it can't easily be checked for string literal
non-const-ness?
The two cases don't seem sufficiently analogous to draw
any useful conclusions.
A better option would be for the Standard to mandate a compiler
option to give a diagnostic if a string literal is used as a
'char *' rather than a 'const char *'. Some groups like 'const'
and use it a lot; others use it only when necessary. I think
it's better not to change the language itself but simply make
sure better tools are there for people who want or need them, and
let different groups decide independently. This approach also is
better suited for acceptance in the development community, not
to mention allowing easier transitioning of old programs.
