In article <42****************@news.xs4all.nl>, Richard Bos wrote:
Nils Weller <me@privacy.net> wrote:
the deprecation and removal of nonstandard gcc features. The 4.0 series,
for example, removes support for the -fwritable-strings option (which
permits a program to modify string constants, causing undefined behavior
according to ISO C), so there may be much broken legacy code out there
that will have to be fixed for 4.x.
Good. Code which relies on this option is broken in the first place, so
forcing its repair is a beneficial effect.
Richard, mildly surprised at this new clue shown by gcc
Obviously, I agree with the essence of your statement, but I don't agree
with the implied criticism of the gcc team for introducing this option
in the first place ...
gcc is a large project that addresses the needs of a wide variety of
users. Some of these users still have to deal with pre-ANSI C code
today, whereas many others had to deal with it at one time or another,
particularly in the first couple of years after the adoption of ANSI C
(remember that gcc was already around before C89 was even finished.) As
you may know, K&R C did not forbid you to modify string constants. A
classical example of a place where some people chose to use a string
constant in place of a modifyable character array is the Unix function
mktemp(), which modifies its string argument.
ANSI C says that attempting to modify a string constant invokes
``undefined behavior''; An unfortunate side effect of this fact is that
any code which does this, while illegal, may happen to work just as
expected - with K&R C semantics! Therefore, some ANSI compilers (Borland
comes to mind) still choose to make string constants writable by
default, so that even new code may be broken in this way *by accident*.
The -fwritable-strings option (which is implied by gcc's -traditional
option, by the way) does not exist so that you can write code that
modifies string constants; It exists so that you can more easily port
(presumably pre-ANSI) code that relies on this ability. Thus, it does a
service to those who need to get the job done as quickly and as easily
as possible, and there are many potential cases where this feature works
just fine and the problem is never encountered again. And it's just one
of many system software inventions that exist solely to provide
compatibility with legacy and/or nonportable code. Other examples are
the ability to dereference null pointers and misaligned load/store
instruction emulation for architectures that do not naturally support
this.
In any case, it's important to keep in mind that gcc's user community
does not only consist of people who care about code correctness, and not
everyone will always agree that it's better to fix the code than to use
a compiler option like this one. Perhaps you will only have to use the
code once and can throw it away afterwards. Compatibility features to
run nonportable code tend to address the needs of an ``end user''; An
end user of a program does not care about code quality and correctness,
he may not be capable of debugging the code, and it just has to work no
matter how. If you *abuse* a compatibility feature as a means to write
buggy, yet working code, then it's not the fault of the implementor.
--
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
