C89 question: Do we need to accept -Wint-conversion warnings

C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

Are these code fragments valid C89 code?

  int i1 = 1;
  char *p1 = i;

  char c;
  char *p2 = &c;
  int i2 = p2;

Or can we generate errors for them even with -std=gnu89?

(It will still be possible to override this with -fpermissive or
-Wno-int-conversion.)

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
wrote:

> Are these code fragments valid C89 code?
>
>   int i1 = 1;
>   char *p1 = i;
>
>   char c;
>   char *p2 = &c;
>   int i2 = p2;
>
> Or can we generate errors for them even with -std=gnu89?
>
> (It will still be possible to override this with -fpermissive or
> -Wno-int-conversion.)
>

Given that C89 code is unlikely to be actively maintained, I think we
should be permissive by default in that mode.  People compiling with an old
-std flag are presumably doing it to keep old code compiling, and it seems
appropriate to respect that.

I'm also (though less strongly) inclined to be permissive in C99 mode, and
only introduce the new strictness by default for C11/C17 modes.

Jason

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Jakub Jelinek]

On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> wrote:
> 
> > Are these code fragments valid C89 code?
> >
> >   int i1 = 1;
> >   char *p1 = i;
> >
> >   char c;
> >   char *p2 = &c;
> >   int i2 = p2;
> >
> > Or can we generate errors for them even with -std=gnu89?
> >
> > (It will still be possible to override this with -fpermissive or
> > -Wno-int-conversion.)
> >
> 
> Given that C89 code is unlikely to be actively maintained, I think we
> should be permissive by default in that mode.  People compiling with an old
> -std flag are presumably doing it to keep old code compiling, and it seems
> appropriate to respect that.

Yeah, complete agreement here.

> I'm also (though less strongly) inclined to be permissive in C99 mode, and
> only introduce the new strictness by default for C11/C17 modes.

Especially when the default is -std=gnu17 that can be an option as well.

There might be some code in the wild compiled with -std=gnu99 or -std=c99 just
because it wanted to use C99 features back 15-20 years ago and hasn't been
adjusted since then, but it might be better to adjust that if needed and keep
using those flags only when they are needed because the code isn't C11/C17/C2X
ready.

	Jakub

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Joseph Myers]

On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote:

> Are these code fragments valid C89 code?
> 
>   int i1 = 1;
>   char *p1 = i;
> 
>   char c;
>   char *p2 = &c;
>   int i2 = p2;

Implicit conversions between pointers and integers are not valid C89.

ANSI C89, as adopted as FIPS PUB 160, is available from NIST: 
https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

* Jakub Jelinek:

> On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
>> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
>> wrote:
>> 
>> > Are these code fragments valid C89 code?
>> >
>> >   int i1 = 1;
>> >   char *p1 = i;
>> >
>> >   char c;
>> >   char *p2 = &c;
>> >   int i2 = p2;
>> >
>> > Or can we generate errors for them even with -std=gnu89?
>> >
>> > (It will still be possible to override this with -fpermissive or
>> > -Wno-int-conversion.)
>> >
>> 
>> Given that C89 code is unlikely to be actively maintained, I think we
>> should be permissive by default in that mode.  People compiling with an old
>> -std flag are presumably doing it to keep old code compiling, and it seems
>> appropriate to respect that.
>
> Yeah, complete agreement here.

Okay.  It helps with the test suite conversation because -std=gnu89 -w
is available today, so I can post such patches separately.

>> I'm also (though less strongly) inclined to be permissive in C99 mode, and
>> only introduce the new strictness by default for C11/C17 modes.
>
> Especially when the default is -std=gnu17 that can be an option as well.
>
> There might be some code in the wild compiled with -std=gnu99 or -std=c99 just
> because it wanted to use C99 features back 15-20 years ago and hasn't been
> adjusted since then, but it might be better to adjust that if needed and keep
> using those flags only when they are needed because the code isn't C11/C17/C2X
> ready.

Linux currently uses -std=gnu99 deliberately in a few places, I believe.
It would be a shame if we defaulted to permissive mode over there.  I
would certainly prefer to restrict permissive mode to the C89/C90
language levels.  We can have this discussion once I post my patch
(which depends on Jason's permerror enhancement in several ways).

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

* Joseph Myers:

> On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote:
>
>> Are these code fragments valid C89 code?
>> 
>>   int i1 = 1;
>>   char *p1 = i;
>> 
>>   char c;
>>   char *p2 = &c;
>>   int i2 = p2;
>
> Implicit conversions between pointers and integers are not valid C89.
>
> ANSI C89, as adopted as FIPS PUB 160, is available from NIST: 
> https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf

Thank you, this is helpful information.

Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

On Tue, Oct 10, 2023 at 12:09 PM Florian Weimer via Gcc <gcc@gcc.gnu.org>
wrote:

> * Jakub Jelinek:
>
> > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org
> >
> >> wrote:
> >>
> >> > Are these code fragments valid C89 code?
> >> >
> >> >   int i1 = 1;
> >> >   char *p1 = i;
> >> >
> >> >   char c;
> >> >   char *p2 = &c;
> >> >   int i2 = p2;
> >> >
> >> > Or can we generate errors for them even with -std=gnu89?
> >> >
> >> > (It will still be possible to override this with -fpermissive or
> >> > -Wno-int-conversion.)
> >> >
> >>
> >> Given that C89 code is unlikely to be actively maintained, I think we
> >> should be permissive by default in that mode.  People compiling with an
> old
> >> -std flag are presumably doing it to keep old code compiling, and it
> seems
> >> appropriate to respect that.
> >
> > Yeah, complete agreement here.
>
> Okay.  It helps with the test suite conversation because -std=gnu89 -w
> is available today, so I can post such patches separately.
>
> >> I'm also (though less strongly) inclined to be permissive in C99 mode,
> and
> >> only introduce the new strictness by default for C11/C17 modes.
> >
> > Especially when the default is -std=gnu17 that can be an option as well.
> >
> > There might be some code in the wild compiled with -std=gnu99 or
> -std=c99 just
> > because it wanted to use C99 features back 15-20 years ago and hasn't
> been
> > adjusted since then, but it might be better to adjust that if needed and
> keep
> > using those flags only when they are needed because the code isn't
> C11/C17/C2X
> > ready.
>
> Linux currently uses -std=gnu99 deliberately in a few places, I believe.
> It would be a shame if we defaulted to permissive mode over there.  I
> would certainly prefer to restrict permissive mode to the C89/C90
> language levels.  We can have this discussion once I post my patch
> (which depends on Jason's permerror enhancement in several ways).
>

C99 is what POSIX assumes up to the next version which should be nearing
release. It moves the baseline to C11.

Also from a safety critical system viewpoint, C99 (and C++03) was still
widely used. In fact the FACE Technical Standard gave only those language
versions for application conformance purposes. C++11 and C++14 were
very recently added as options in a corrigenda that was released in August.
I know this isn't the primary focus for GCC but embedded isn't rare.

From an RTEMS perspective, the OS is primarily built as C11 but that
was  primarily done for access to the atomics defined there not in C99.

So it isn't that the code "isn't ready" for a new language version, it may
be because there are standards still based on older versions or the safety
review process may not accommodate a newer version.  It also could be
as simple as the RTOS vendor does not recommend using it with their
OS which has been through something like a flight qualification.

--joel


>
> Thanks,
> Florian
>
>

Re: C89 question: Do we need to accept -Wint-conversion warnings

[David Brown]

On 10/10/2023 18:30, Jason Merrill via Gcc wrote:
> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> wrote:
> 
>> Are these code fragments valid C89 code?
>>
>>    int i1 = 1;
>>    char *p1 = i;
>>
>>    char c;
>>    char *p2 = &c;
>>    int i2 = p2;
>>
>> Or can we generate errors for them even with -std=gnu89?
>>
>> (It will still be possible to override this with -fpermissive or
>> -Wno-int-conversion.)
>>
> 
> Given that C89 code is unlikely to be actively maintained, I think we
> should be permissive by default in that mode.  People compiling with an old
> -std flag are presumably doing it to keep old code compiling, and it seems
> appropriate to respect that.
> 

That is - unfortunately, IMHO - not true.

In particular, in the small-systems embedded development world (and that 
is a /big/ use-case for C programming), there is still a lot done in 
C89/C90.  It is the dominant variety of C for things like RTOS's (such 
as FreeRTOS and ThreadX), network stacks (like LWIP), microcontroller 
manufacturers' SDK's and libraries, and so on.  There are also still 
some microcontrollers for which the main toolchains (not GCC, obviously) 
do not have full C99 support, and there is a significant proportion of 
embedded C programmers who write all their code in C90, even for new 
projects.  There is a "cult" within C coders who think "The C 
Programming Language" is the "Bible", and have never learned anything 
since then.

The biggest target device in this field is the 32-bit ARM Cortex-M 
family, and the the most used compiler is gcc.

Taking numbers out of thin air, but not unrealistically I believe, there 
are millions of devices manufactured every day running code compiled by 
gcc -std=gnu89 or -std=c89 (or an equivalent).

Add to that the libraries on "big" systems that are written to C89/C90 
standards.  After all, that is the lowest common denominator of the 
C/C++ world - with a bit of care, the code will be compatible with all 
other C and C++ standards.  It is not just of old code, though a great 
deal of modern library code has roots back to pre-C99 days, but it is 
also cross-platform code.  It is only relatively recently that 
Microsoft's development tools have had reasonable support for C99 - many 
people writing code to work in both the *nix world and the Windows world 
stick to C89/C90 if they want a clear standard (rather than "the subset 
of C99 supported by the MSVC version they happen to have").

Now, pretty much all of that code could also be compiled with -std=c99 
(or -std=gnu99).  And in a great many cases, it /is/ compiled as C99. 
But for those that want to be careful about their coding, and many do, 
the natural choice here is "-std=c90 -pedantic-errors".


So IMHO (and as I am not a code contributor to GCC, my opinion really is 
humble) it is better to be stricter than permissive, even in old 
standards.  It is particularly important for "-std=c89", while 
"-std=gnu89" is naturally more permissive.  (I have seen more than 
enough terrible code in embedded programs - I don't want to make it 
easier for them to write even worse code!)


> I'm also (though less strongly) inclined to be permissive in C99 mode, and
> only introduce the new strictness by default for C11/C17 modes.
> 

I suspect (again with numbers taken from thin air) that the proportion 
of C programmers or projects that actively choose C11 or C17 modes, as 
distinct from using the compiler defaults, will be less than 1%.  C99 
(or gnu99) is the most commonly chosen standard for small-systems 
embedded programming, combining C90 libraries, stacks, and RTOS's with 
user code in C99.  So again, my preference is towards stricter control, 
not more permissive tools.

I am aware, however, that I personally am a lot fussier than most 
programmers.  I run gcc with lots of additional warnings and 
-Wfatal-errors, and want ever-stricter tools.  I don't think many people 
would be happy with the choices /I/ would prefer for default compiler 
flags!

I am merely a happy GCC user, not a contributor, much less anyone 
involved in decision making.  But I hope it is helpful to you to hear 
other opinions here, especially about small-systems embedded 
programming, at least in my own experience.

David

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

* David Brown:

> So IMHO (and as I am not a code contributor to GCC, my opinion really
> is humble) it is better to be stricter than permissive, even in old
> standards.  It is particularly important for "-std=c89", while
> "-std=gnu89" is naturally more permissive.  (I have seen more than
> enough terrible code in embedded programs - I don't want to make it
> easier for them to write even worse code!)

We can probably make (say) -std=gnu89 -fno-permissive work, in a way
that is a bit less picky than -std=gnu89 -pedantic-errors today.

And of course there's still -Werror, that's not going to go away.  So if
you are using -Werror=implicit-function-declaration today (as you
probably should 8-), nothing changes for you in GCC 14.

> I suspect (again with numbers taken from thin air) that the proportion
> of C programmers or projects that actively choose C11 or C17 modes, as
> distinct from using the compiler defaults, will be less than 1%.  C99
> (or gnu99) is the most commonly chosen standard for small-systems
> embedded programming, combining C90 libraries, stacks, and RTOS's with
> user code in C99.  So again, my preference is towards stricter
> control, not more permissive tools.

I don't think the estimate is accurate.  Several upstream build systems
I've seen enable -std=gnu11 and similar options once they are supported.
Usually, it's an attempt to upgrade to newer language standards that
hasn't aged well, not a downgrade.  It's probably quite bit more than
1%.

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[David Brown]

On 11/10/2023 10:10, Florian Weimer wrote:
> * David Brown:
> 
>> So IMHO (and as I am not a code contributor to GCC, my opinion really
>> is humble) it is better to be stricter than permissive, even in old
>> standards.  It is particularly important for "-std=c89", while
>> "-std=gnu89" is naturally more permissive.  (I have seen more than
>> enough terrible code in embedded programs - I don't want to make it
>> easier for them to write even worse code!)
> 
> We can probably make (say) -std=gnu89 -fno-permissive work, in a way
> that is a bit less picky than -std=gnu89 -pedantic-errors today.
> 

The gcc manual has "-permissive" under "C++ Dialect Options".  Are you 
planning to have it for C as well?  That sounds like a good idea 
(perhaps with some examples in the documentation?).  Ideally (and I 
realise I like stricter checking than many people) some long-obsolescent 
features like non-prototype function declarations could be marked as 
errors unless "-permissive" were used, even in C89 standards.

(As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing" should 
be listed under "C Dialect Options", as they give specific semantics to 
normally undefined behaviour.)


> And of course there's still -Werror, that's not going to go away.  So if
> you are using -Werror=implicit-function-declaration today (as you
> probably should 8-), nothing changes for you in GCC 14.

I have long lists of explicit warnings and flags in my makefiles, so I 
am not concerned for my own projects.  But I always worry about the less 
vigilant users - the ones who don't know the details of the language or 
the features of the compiler, and don't bother finding out.  I don't 
want default settings to be less strict for them, as it means higher 
risks of bugs escaping out to released code.

> 
>> I suspect (again with numbers taken from thin air) that the proportion
>> of C programmers or projects that actively choose C11 or C17 modes, as
>> distinct from using the compiler defaults, will be less than 1%.  C99
>> (or gnu99) is the most commonly chosen standard for small-systems
>> embedded programming, combining C90 libraries, stacks, and RTOS's with
>> user code in C99.  So again, my preference is towards stricter
>> control, not more permissive tools.
> 
> I don't think the estimate is accurate.  Several upstream build systems
> I've seen enable -std=gnu11 and similar options once they are supported.
> Usually, it's an attempt to upgrade to newer language standards that
> hasn't aged well, not a downgrade.  It's probably quite bit more than
> 1%.
> 

Fair enough.  My experience is mostly within a particular field that is 
probably more conservative than a lot of other areas of programming.

David

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

* David Brown:

> On 11/10/2023 10:10, Florian Weimer wrote:
>> * David Brown:
>> 
>>> So IMHO (and as I am not a code contributor to GCC, my opinion really
>>> is humble) it is better to be stricter than permissive, even in old
>>> standards.  It is particularly important for "-std=c89", while
>>> "-std=gnu89" is naturally more permissive.  (I have seen more than
>>> enough terrible code in embedded programs - I don't want to make it
>>> easier for them to write even worse code!)
>> We can probably make (say) -std=gnu89 -fno-permissive work, in a way
>> that is a bit less picky than -std=gnu89 -pedantic-errors today.
>> 
>
> The gcc manual has "-permissive" under "C++ Dialect Options".  Are you
> planning to have it for C as well?

Yes, I've got local patches on top of Jason's permerror enhancement:

  [PATCH v2 RFA] diagnostic: add permerror variants with opt
  <https://inbox.sourceware.org/gcc-patches/20231003210916.1027930-1-jason@redhat.com/>


> That sounds like a good idea (perhaps with some examples in the
> documentation?).  Ideally (and I realise I like stricter checking than
> many people) some long-obsolescent features like non-prototype
> function declarations could be marked as errors unless "-permissive"
> were used, even in C89 standards.

For some of such declarations, this falls out of the implicit-int
removal.

C23 changes meaning of of extern foo(); to match the C++ interpretation
of extern foo(void);.  I don't think we should warn about that.  If we
warn, it would be at the call site.

> (As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing"
> should be listed under "C Dialect Options", as they give specific
> semantics to normally undefined behaviour.)

They are code generation options, too.

>> And of course there's still -Werror, that's not going to go away.  So if
>> you are using -Werror=implicit-function-declaration today (as you
>> probably should 8-), nothing changes for you in GCC 14.
>
> I have long lists of explicit warnings and flags in my makefiles, so I
> am not concerned for my own projects.  But I always worry about the
> less vigilant users - the ones who don't know the details of the
> language or the features of the compiler, and don't bother finding
> out.  I don't want default settings to be less strict for them, as it
> means higher risks of bugs escaping out to released code.

We have a tension regarding support for legacy software, and ongoing
development.  I think we should draw the line at C99.  That's the first
language standard that removes most of these obsolescent features, after
all.

Thanks,
Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

[David Brown]

On 11/10/2023 12:17, Florian Weimer wrote:
> * David Brown:
> 
>> On 11/10/2023 10:10, Florian Weimer wrote:
>>> * David Brown:
>>>
>>>> So IMHO (and as I am not a code contributor to GCC, my opinion really
>>>> is humble) it is better to be stricter than permissive, even in old
>>>> standards.  It is particularly important for "-std=c89", while
>>>> "-std=gnu89" is naturally more permissive.  (I have seen more than
>>>> enough terrible code in embedded programs - I don't want to make it
>>>> easier for them to write even worse code!)
>>> We can probably make (say) -std=gnu89 -fno-permissive work, in a way
>>> that is a bit less picky than -std=gnu89 -pedantic-errors today.
>>>
>>
>> The gcc manual has "-permissive" under "C++ Dialect Options".  Are you
>> planning to have it for C as well?
> 
> Yes, I've got local patches on top of Jason's permerror enhancement:
> 
>    [PATCH v2 RFA] diagnostic: add permerror variants with opt
>    <https://inbox.sourceware.org/gcc-patches/20231003210916.1027930-1-jason@redhat.com/>
> 
> 
>> That sounds like a good idea (perhaps with some examples in the
>> documentation?).  Ideally (and I realise I like stricter checking than
>> many people) some long-obsolescent features like non-prototype
>> function declarations could be marked as errors unless "-permissive"
>> were used, even in C89 standards.
> 
> For some of such declarations, this falls out of the implicit-int
> removal.

Yes.

> 
> C23 changes meaning of of extern foo(); to match the C++ interpretation
> of extern foo(void);.  I don't think we should warn about that.  If we
> warn, it would be at the call site.

I'm not sure I fully agree.  "extern foo();" became invalid when 
implicit int was removed in C99.  But "extern T foo();", where "T" is 
void or any type, has changed meaning between C17 (and before) and C23.

With C23, it means the same as "extern T foo(void);", like in C++ (and 
like all C standards if it is part of the definition of the function). 
However, prior to C23, a declaration of "T foo();" that is not part of 
the definition of the function declares the function and "specifies that 
no information about the number or types of the parameters is supplied". 
  This use was obsolescent from C90.

To my mind, this is very different.  I think it is fair to suppose that 
for many cases of pre-C23 declarations with empty parentheses, the 
programmer probably meant "(void)".  But the language standards have 
changed the meaning of the declaration.

IMHO I think calling "foo" with parameters should definitely be a 
warning, enabled by default, for at least -std=c99 onwards - it is 
almost certainly a mistake.  (Those few people that use it as a feature 
can ignore or disable the warning.)  I would also put warnings on the 
declaration itself at -Wall, or at least -Wextra (i.e., 
"-Wstrict-prototypes").  I think that things that change between 
standards, even subtly, should be highlighted.  Remember, this concerns 
a syntax that was marked obsolescent some 35 years ago, because the 
alternative (prototypes) was considered "superior to the old style on 
every count".

It could be reasonable to consider "extern T foo();" as valid in 
"-std=gnu99" and other "gnu" standards - GCC has an established history 
of "back-porting" useful features of newer standards to older settings. 
But at least for "-std=std99" and other "standard" standards, I think it 
is best to warn about the likely code error.

> 
>> (As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing"
>> should be listed under "C Dialect Options", as they give specific
>> semantics to normally undefined behaviour.)
> 
> They are code generation options, too.

I see them as semantic extensions to the language, and code generation 
differences are a direct result of that (even if they historically arose 
as code generation options and optimisation flags respectively). 
Perhaps they could be mentioned or linked to in the C dialect options 
page?  Maybe it would be clearer to have new specific flags for the 
dialect options, which are implemented by activating these flags? 
Perhaps that would be confusing.

> 
>>> And of course there's still -Werror, that's not going to go away.  So if
>>> you are using -Werror=implicit-function-declaration today (as you
>>> probably should 8-), nothing changes for you in GCC 14.
>>
>> I have long lists of explicit warnings and flags in my makefiles, so I
>> am not concerned for my own projects.  But I always worry about the
>> less vigilant users - the ones who don't know the details of the
>> language or the features of the compiler, and don't bother finding
>> out.  I don't want default settings to be less strict for them, as it
>> means higher risks of bugs escaping out to released code.
> 
> We have a tension regarding support for legacy software, and ongoing
> development.  

Agreed, and I fully understand that there is no easy answer here.  On 
the one hand, you don't want to break existing code bases or build 
setups, and on the other hand you want to help developers write good 
code (and avoid bad code) going forwards.

> I think we should draw the line at C99.  That's the first
> language standard that removes most of these obsolescent features, after
> all.
> 

C99 removed implicit int and implicit function declarations (though 
these are still merely warnings by default in GCC!).  Non-prototype 
function declarations were not removed until C23, and some things (minor 
issues, to be fair) have been explicitly marked obsolescent from C89 up 
to and including C23 !

Still, I fully agree with the principle of being stricter for later 
standards versions than older standards versions.  Having had to 
maintain code where a function's definition, declarations and uses 
varied wildly in parameter types and count throughout a program, I am 
favour of anything that makes it harder for people to write such 
nonsense and claim "it compiles, let's ship it!".

I appreciate your taking the time to read and consider my opinions, 
whether you implement any of them or not.  And - as always - thank you 
all for your work on GCC.

David

Re: C89 question: Do we need to accept -Wint-conversion warnings

[Florian Weimer]

* David Brown:

>> C23 changes meaning of of extern foo(); to match the C++
>> interpretation of extern foo(void);.  I don't think we should warn
>> about that.  If we warn, it would be at the call site.
>
> I'm not sure I fully agree.  "extern foo();" became invalid when
> implicit int was removed in C99.  But "extern T foo();", where "T" is
> void or any type, has changed meaning between C17 (and before) and
> C23.

My concern is that the warning would not really be actionable.
Encouraging programmers to change foo() to foo(void) in declarations
seems merely busywork.  C++ doesn't need this, and future C won't need
it, either.

> IMHO I think calling "foo" with parameters should definitely be a
> warning, enabled by default, for at least -std=c99 onwards - it is
> almost certainly a mistake.  (Those few people that use it as a
> feature can ignore or disable the warning.)

It's possible to disable this warning in C23 by declaring foo as ”extern
T foo(...);”.  Not sure if this has ABI implications.

> I would also put warnings on the declaration itself at -Wall, or at
> least -Wextra (i.e., "-Wstrict-prototypes").  I think that things that
> change between standards, even subtly, should be highlighted.
> Remember, this concerns a syntax that was marked obsolescent some 35
> years ago, because the alternative (prototypes) was considered
> "superior to the old style on every count".

I still think the declaration is quite harmless if we warn at call
sites.

Thanks,
Florian