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

David Brown david@westcontrol.com
Wed Oct 11 08:51:37 GMT 2023



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






More information about the Gcc mailing list