Jakub Jelinek wrote:
> You are probably looking for bug compatibility, and that isn't something
> GCC guarantees, definitely not between major versions.
And that's one half of what I'm complaining about.
> The C/C++ standards (and standards governing the extensions to the
> languages) is what matters, if you write standard conforming code, GCC
> won't (intentionally) start rejecting it. But if you have code that
> happens to compile because of some GCC bug, eventhough it was invalid, or
> some C/C++ defect report clarifies some corner case, you need to be
> prepared to fix up your code.
What about those documented extensions that got deprecated and later
removed? That's the second half of what I'm complaining about: even things
which are NOT bugs but documented extensions get deprecated and soon later
removed.
IMHO a compiler should accept code whenever there's a sane interpretation of
it, no matter whether it conforms to some standard or not (in fact, this
used to be a GCC design principle, but sadly no longer is these days), and
code which has been compiling for years definitely has a sane
interpretation.
(If you ever look at TIGCC, you'll also notice that TIGCC's GCC is patched
to re-add things like multi-line string literals, lvalue casts, labels at
the end of compound statements etc. More and more patches I'm applying to
the GCC in TIGCC are to readd things GCC removed. TIGCC also enables -fms-
extensions by default (in C, this allows at least unnamed struct/union
fields). I haven't been updating TIGCC's GCC in a while, but I'm sure that
if I do, there'll be another bunch of such patches to add. And that's only
for C, g++ is much worse.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
