[Bug c/85678] -fno-common should be default

david at westcontrol dot com gcc-bugzilla@gcc.gnu.org
Mon Nov 25 18:12:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #11 from David Brown <david at westcontrol dot com> ---
Reliance on -fcommon has not been correct or compatible with any C standard (I
don't think it was even right for K&R C).  If the code is written correctly
(with at most one definition of all externally linked symbols) then -fcommon
does not make it incorrect or conflict with the standards.  But if your code
requires -fcommon to compile correctly, it does not conform to C89 or anything
newer.

Personally, I'd like to see many old and dangerous C practices give errors by
default.  Along with common symbols, I'd include non-prototype function
declarations and definitions, and calling functions without declaring them. 
These are the kind of thing you'd expect to see in pre-ANSI C - other than
that, they  are probably errors in the code.  It is good that gcc still
supports such code, but I think making them errors by default will reduce bugs
in current code.  And surely that is worth the cost of adding a "-fold-code"
flag to ancient build recipes?  (The "-fold-code" flag could probably also
imply "-fno-strict-aliasing -fwrapv" to deal with other assumptions sometimes
made in older code.)

There is precedence for this.  The default standard for gcc changed from
"gnu89" to "gnu11".  While most "gnu89" code will compile with the same
semantics in "gnu11" mode, there are a fair number of incompatibilities. 
Changing the default to "-fno-common" (and ideally "-Werror=strict-prototypes
-Werror=old-style-declaration -Werror=missing-parameter-type") would have a lot
smaller impact than changing the default standard.


More information about the Gcc-bugs mailing list