On 06/22/2018 11:19 AM, Joseph Myers wrote:
On Thu, 21 Jun 2018, Eric Gallager wrote:
On 6/21/18, Jeff Law <l...@redhat.com> wrote:
On 06/12/2018 11:21 AM, Joseph Myers wrote:
On Tue, 12 Jun 2018, Martin Sebor wrote:
The proposal to enable -Wstrict-prototypes discussed below
was considered too late for GCC 8. I'd like to revive it
now for GCC 9.
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00935.html
My point from that discussion stands that () for no arguments should be
considered separately from warning for all the other cases.
There's a lot of legacy code out there... What's the proposal for
handling the no argument () case? Are we thinking multiple levels? And
if so what's the default?
-Wstrict-prototypes and -Wstricter-prototypes for the prototypes case?
And then split
-Wold-style-definition into -Wold-style-definition and
-Wc++-style-definition for the equivalent use of () in function
definitions?
I think the existing options, when explicitly used, should keep warning
for all the cases they currently warn for, including (), even if you also
have new warning options available that correspond to a subset of the
existing options.
It's the possible enabled-by-default warnings that I think should be a
subset, as I don't think using () for no-argument functions is such an
obsolescent practice as using old-style definitions, or () declarations,
for functions with arguments (especially since () for no-argument
functions is perfectly idiomatic in C++, and if C obsoletes non-prototype
functions I'd expect it to end up with () having the same meaning as in
C++, rather than being disallowed).
I assume you mean if C removes non-prototype functions (they are
obsolete today and have been since C99). At that point this will
be moot since GCC will presumably give an error for a declaration
without a prototype (or treat it as (void)). But that time is
a long ways away (2022 at the earliest). Until then, one of
the coding mistakes to detect is providing no arguments to
a ()-declared function that's defined to take at least one.
Subsetting the warning and not diagnosing such declarations (or
calls to them) will leave a big gap in the detection. I'm still
thinking about how to approach this under your constraint but
I don't think it's worth either the effort to implement or
the false negatives that seem unavoidable.
The vast bulk of the places where that previous patch changes testcases
are for (), which would not need changing under my proposal.
Sure. I think we could easily exempt most of the tests from
diagnosing without compromising the efficacy of the warning
by silently accepting definitions of () functions that take no
arguments (and diagnosing calls to them that pass some). What
I think is important to preserve is diagnosing () declarations.
It might be possible to try to make the warning less noisy and
only have it complain for declarations actually used to call
functions. Or try to do something even more clever and look
for call patterns to () functions (e.g., diagnose only those
that are called with different numbers or types of arguments
in the same file). But as I said, I'm not sure that what is
to be gained by this is worth the effort.
Martin
