This is the mail archive of the
mailing list for the GCC project.
Re: No more multiline string constants
- To: Per Bothner <per at bothner dot com>
- Subject: Re: No more multiline string constants
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Thu, 5 Jul 2001 18:04:19 -0700
- Cc: gcc-patches at gcc dot gnu dot org, Neil Booth <neil at daikokuya dot demon dot co dot uk>
On Thu, Jul 05, 2001 at 04:42:41PM -0700, Per Bothner wrote:
> "Zack Weinberg" <email@example.com> writes:
> > This patch removes the deprecated feature of multiline string
> > constants.
> Just a minute! I'm not sure we really agreed that this was a good
> idea. I do know that Stallman is strongly opposed to removing this
> feature. (It is possible this debate was internal to the steering
> commitee, in which case I apolize on behalf of the SC for not
> resolving and communicating this.)
I certainly was not aware of any such discussion. Removing the
feature was discussed some time ago on the public lists, and it was
my impression that it had met with general approval.
I'd like to state my agreement with Geoff's statement that SC
discussions should be public. I'd also like to state that in my
opinion, Stallman's opinion should count no more and no less than any
other experienced user's opinion.
> What is the reason for removing this feature, except that it is
> "non-standard", and there are other (standard) ways of achieving
> the same effect? Note that those other standard ways are
> arguably quite a bit uglier.
There are three major arguments in my mind for removing the feature.
- It is not merely an extension; it is a dangerous extension.
Precisely because multiline strings are easy to use, and prettier
than the standard alternatives, people use them. GCC accepts them
without comment, so many people think they are part of the
standard. However, there is no way to write code which makes use
of multi-line strings only when compiled by GCC. The poor schmuck
who ports code to a different compiler therefore has to go back
and edit them all. It is easy to introduce errors while doing
Extensions such as __attribute__, by contrast, are obviously
specific to GCC, and can easily be rendered harmless when code is
compiled with other compilers.
I am aware that the official position of the FSF is that
portability to other compilers is not terribly important. I
disagree with this position in the strongest possible terms. We
do no one a service by making it difficult to move code to other
- Its semantics are ill-defined.
For instance: is
identical to "foo\nbar"? What if the host and target have
different line-ending conventions? What if there is invisible
whitespace between foo and the end of the line?
GCC 2.7, 2.95, and 3.0 answer the above questions differently, and
in no case are the answers documented. And there are not
obviously correct answers to any of them, nor have I enumerated
all of the issues.
This is the major reason why multi-line strings do not appear in
the standard, incidentally.
- It interferes with good diagnostics and error recovery.
An accidental stray " in the middle of a line will cause the
compiler to treat all code from then on as strings and all strings
from then on as code. The usual effect is a flood of useless
error messages. Without the extension, the compiler will get
itself back in sync at the end of the line.
There is only one argument in my mind for keeping them:
- It makes it easier to write lengthy chunks of inline assembly.
This is certainly true, however, writing a lengthy chunk of inline
assembly is almost always a mistake; it interferes with the compiler's
ability to do its job. Therefore I do not think there is any
compelling need to make that easy.
zw This is, no doubt, the rational strategy; quite possibly the
only one that will work. But it ignores the exigiencies of
the tenure system and is therefore impractical.
-- Jerry Fodor, _The Mind Doesn't Work That Way_