Re: Baby X is bor nagain

Michael S <already5chosen@yahoo.com> writes:

On Sun, 30 Jun 2024 17:54:14 +0200
David Brown <david.brown@hesbynett.no> wrote:
>

On 30/06/2024 11:18, Michael S wrote:
>

On Sat, 29 Jun 2024 20:55:54 +0100
bart <bc@freeuk.com> wrote:
>

On 29/06/2024 18:46, Richard Harnden wrote:
>

On 29/06/2024 15:14, bart wrote:
[...]
>

My older bcc compiler reported 4 as a hard error unless an
override was used.

>
But you didn't say anything about main's args.

>
I did, indirectly.  The actual error was the use of "()" as an empty
parameter list (for any function, not just main, but my example
could also have been 'void H(){H(123);}').  If you tried to compile:
>
     int main() {
         main(123);
     }
>
then it wouldn't get past the () to the call.
>
Eventually I dropped that restriction, and the reason was that so
much code used such parameter lists, for any function.
>
Not because they wanted unchecked args (there are some legitimate
use-cases within function pointer types), but because so many
people assumed () meant zero parameters like (void).
>
Why was such code so common?  Presumably because compilers said
nothing;  and they couldn't because the language allowed it.  If they
had required an override like mine did, more would have got the
message.

>
I tried following code:
int foo() { return 1; }
>
Both MSVC and clang warn about it at high warnings level (-Wall for
MSVC, -Wpedantic for clang).  But they dont warn at levels that most
people use in practice (-W3 or -W4 for MSVC, -Wall for clang).
gcc13 produces no warning even at -Wpedantic.  It does produce
warning with '-Wpedantic -std=xxx' for all values of xxx except c23
and gnu23.  The absence of warning for c23/gnu23 makes sense, the
rest of gcc behavior - less so.

>
gcc -Wpedantic makes very little sense without specifying a C
standard (rather than a gnu C standard).
>
But why would you expect a warning from code that is perfectly legal
and well-defined C code, without explicitly enabling warnings that
check for particular style issues?  Non-prototype function
declarations are deprecated (since C99), but not removed from the
language until C23 (where that declaration is now a function
prototype).

>
I expect warning at -Wall, because it is deprecated.  Those who do
not want warning can turn it off explicitly with -Wno-strict-prototypes
or whatever the name of the switch.

I would like to offer a different view.

To me the behavior of -Wall is kind of a "fuck you" from the gcc
people.  If a compile is done with, for example,

    gcc -std=c99 -pedantic -Wall ...

the empty () were not deprecated for C99 (and in fact still
are not since C23 hasn't been ratified yet).  The attitude
towards -Wall that it can change at any time - without regard
to what -std=c?? option is given - effectively makes it
useless, because it can't be relied on.  gcc has any number
of diagnostic options, but many or most of the prominent ones
change over time and so have to be avoided if one wants
repeatable behavior.  I would happily settle for things like,
say, -Wall99 or -Wall11 (that's two ells and two ones), but
of course gcc doesn't provide stable diagnostic aggregates,
only frustratingly ever-changing ones.