Re: No more multiline string constants

[Zachary Weinberg <zackw at stanford dot edu>]

Gaute B Strokkenes <gs234@cam.ac.uk> said: 

> 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 be willing to consider that as a transition plan.  The C++ front
end already has a similar concept (-fpermissive).  I don't want that
to be the permanent solution, because it does nothing to improve the
maintainability of the preprocessor and C front end.  It may in fact
make it harder to maintain them, since the code is no longer active
by default and therefore more prone to bit rot.

> I'd also argue that 2) can be addressed by picking a sensible
> interpretation and sticking to it.

That would have been true if the sensible interpretation had been
chosen, documented, and stuck to when the feature was implemented.
This is not what actually happened.  2.95 and before, 2.96 as
distributed by Red Hat, and 3.0 all do it differently, and none of
them documents the semantics.  [The common case, i.e. Unix line
terminators and no trailing whitespace on any line, is handled the
same across all three versions.  However, it is proper to worry about
the corner cases when discussing extensions, since it is precisely
those cases that cause 90% of the trouble.]

> > [...] 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.

Yes, there are good and legitimate reasons for users to want inline
assembly.  I would argue that nearly all legitimate uses of multiline
assembly are better served either by a series of single-line asm()
statements, or a separate file of pure assembly language.  Now I do not
claim to be familiar with all the myriad uses people have found for
asm().  It may be that there are things not adequately handled by anything
other than a multiline asm statement.  In that case, perhaps we ought to
look for ways to improve asm() so that it does not need multi-line strings
to do its job.  Features of asm() have a much narrower impact on the
language than features of the lexical analyzer.

> 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.

I would like to point out another concern which people have to date
ignored, in this thread.  Each individual extension, considered in
isolation, may be found to be useful and to not add too much extra
complexity to the compiler.  However, the compiler doesn't implement
each extension in isolation; it implements them all at the same time.
The aggregate complexity burden of all the extensions together is
larger than the total burden of each considered in isolation, because
one must consider interactions between extensions.  And therefore
removing one extension may well cause an improvement in maintainability
out of apparent proportion to the size of the diff that removes it.

Readers of linux-kernel should think about the periodic arguments against
additional features of the kernel, expressed in these terms: your new
feature may only cause a 5% performance hit, but after five such features
are added, the kernel, therefore the entire computer, will run *at least*
1 - (.95)^5 = 22% slower.  No, extensions don't normally impact compiler
speed, but I'd say a 25% overhead in maintaining the compiler due to
all its extensions, compared to the difficulty of maintaining a compiler
that implements standard C and nothing else, is not out of the question.

zw