https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=82922
--- Comment #14 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to David Brown from comment #11)
> 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.
Related: bug 82922
