Building the whole Debian archive with GCC 4.1: a summary [LWN.net]

Building the whole Debian archive with GCC 4.1: a summary

Posted Mar 28, 2006 15:00 UTC (Tue) by foo-bar (guest, #22971)
In reply to: Building the whole Debian archive with GCC 4.1: a summary by butlerm
Parent article: Building the whole Debian archive with GCC 4.1: a summary

For example, the ISO C++ people, in their infinite wisdom, decided that anything resembling an offsetof() was to be illegal in C++ in all circumstances, breaking both C compatibility and a *large* body of C++ code. Granted offsetof() is not particularly well defined in cases where there are multiple base classes, but since when is a "C" style language the arbiter of correct programming practice?

GCC does have various extensions to ISO standard. These extensions are well documented and were added intentionally. Apparently offsetof(non-POD) didn't deserve to become an extension and hence was removed.

All I can say is it is unusually irritating for GCC to disallow what used to be perfectly legal idiom with well defined semantics and then not provide some sort of backward compatibility option or other work around.

Anything that is not spelled in the ISO standard and is not defined as GCC extension is illegal by the definition. The fact that it worked doesn't make it a "legal idiom". Writing such code is a mistake that the author is solely responsible for, and nobody has any moral obligation to provide any work arounds not even talking about backward compatibility which implies allowing illegal idioms in the future.

IMHO :-)

(Log in to post comments)

Building the whole Debian archive with GCC 4.1: a summary

Posted Mar 29, 2006 5:22 UTC (Wed) by butlerm (subscriber, #13312) [Link]

This is not something that just accidentally happened to work. The ISO C++ standard was not released until 1998. C++ had a 15 year history prior to that, and taking the offset of a class member was universally portable prior to that time.

But somehow, perhaps in a fit of Java envy, the ISO C++ folks decided that the C++ language should define an virtual abstraction far removed from its origins as a system programming language, and forbade perfectly well defined behavior. Not just declared the result to be "undefined" as sane standards bodies are wont to do, but forbade its use outright, breaking a large body of existing code.

And as one might expect, there is now speculation that the next version of the ISO C++ standard will remove this ridiculously pointless restriction.

Building the whole Debian archive with GCC 4.1: a summary

Posted Mar 29, 2006 14:19 UTC (Wed) by butlerm (subscriber, #13312) [Link]

I should substitute "let the construct suffer in benign neglect" for "declare the result to be undefined". GCC has added an option (-Wno-invalid-offset-of) that eliminates the need for class data member offset gymnastics as well.

Building the whole Debian archive with GCC 4.1: a summary

Posted Mar 29, 2006 18:33 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

As you say, the ISO standard came out in 1998 (it was actually complete in December 1997, and only details have changed since draft standards put out in 1996). You've had more than eight years to fix your code.

Unfortunately, g++ 2.x accepted all kinds of bizarre stuff, and broke on all kinds of standard C++. The GCC developers made the decision to follow the standard. Unfortunately, too many folks in FLOSS-land never used any compiler other than g++, and never cracked a book on C++, so they just threw stuff at the compiler and accepted whatever the compiler let through. That was never a wise strategy.

C++ is the most complex of the widely used languages, and is hard to get right. Generally speaking, GCC has done very well, considering the massively difficult challenges.

There are a few cases where I would agree that GCC 4.1 is a bit too anal-retentive. However, for most of the cases that affect Debian code this is not the issue: if the compiler does not properly enforce the namespace rules, valid C++ programs break (because of name collisions or selecting the wrong overloaded function), and the only way to fix the breakage is to make changes that cause invalid programs that used to compile, to stop working.