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

[David Brown <david@westcontrol.com>]

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