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

[Florian Weimer <fweimer@redhat.com>]

* 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