This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: No more multiline string constants
- To: "Zack Weinberg" <zackw at Stanford dot EDU>
- Subject: Re: No more multiline string constants
- From: Gaute B Strokkenes <gs234 at cam dot ac dot uk>
- Date: Sat, 14 Jul 2001 12:56:26 +0200
- Cc: Per Bothner <per at bothner dot com>, gcc-patches at gcc dot gnu dot org, Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Organization: The Church of Emacs
- References: <20010705180419.H1926@stanford.edu>
On Thu, 5 Jul 2001, zackw@Stanford.EDU wrote:
>
> - It is not merely an extension; it is a dangerous extension.
[snip]
> - Its semantics are ill-defined.
[snip]
> - It interferes with good diagnostics and error recovery.
I believe that concerns 1) and 3) would be equally well addressed by
only allowing multiline strings when a particular switch is passed to
the compiler. Or you could have the compiler emit a warning which
people who actually want to use this extension could turn off. My
point is that simply removing the extension in toto is a very drastic
measure.
I'd also argue that 2) can be addressed by picking a sensible
interpretation and sticking to it. Moreover, people who use inline
assembly are unlikely to care much about a bit of whitespace in any
case.
> - 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.
Proof by blatant assertion detected! Sorry, but there are good and
legitimate reasons for why users want inline assembly. For instance,
no one in their right mind would suggest that e.g. the Linux kernel
should not use inline assembly. GCC should try to accommodate these
users in the same way that it tries to accommodate other users. It's
silly to discriminate against them because they have needs that are
not covered by ISO C.
In general, I do not think that a maintainer should remove a
documented feature that users rely on because, in the view of the
maintainer, the feature is not "clean" or has a potential for abuse.
On the other hand, it might be the case that removing the extension
would significantly simplify the logic of GCC, improve maintainability
and speed and so on. That might be a good reason to remove the
extension; it would be necessary to weigh the discomfort to the users
caused by the removal versus the discomfort to the maintainers caused
by not removing the feature.
--
Gaute Strokkenes http://www.srcf.ucam.org/~gs234/
Here is my refrigerator full of FLANK STEAK...and over there is my
UPHOLSTERED CANOE...I don't know WHY I OWN them!!