Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Sun, 27 Oct 2024 15:21:09 +0100
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <vfli8m$fkhq$1@dont-email.me>
References: <veb5fi$3ll7j$1@dont-email.me>
 <877ca5q84u.fsf@nosuchdomain.example.com> <vf0ijd$3u54q$1@dont-email.me>
 <vf0l98$3un4n$1@dont-email.me> <vf1216$p0c$1@dont-email.me>
 <87y12jpxvl.fsf@nosuchdomain.example.com> <vf1d2o$2hjk$1@dont-email.me>
 <87plnvpgb9.fsf@nosuchdomain.example.com> <vf2sm8$deou$1@dont-email.me>
 <vf7m4s$1d8mj$1@raubtier-asyl.eternal-september.org>
 <vf86uc$1fvt3$1@dont-email.me> <vfit29$3obkb$1@dont-email.me>
 <vfj5up$3q2lf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 27 Oct 2024 15:21:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fb2008f128462439dac0dc9109a21964";
	logging-data="512570"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2SJnop8pr+qeM47sDC3zzo6HtZxOq1DM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qFZM/DVjIS+WSnKEBEvD2b3WGQ8=
Content-Language: en-GB
In-Reply-To: <vfj5up$3q2lf$1@dont-email.me>
Bytes: 6532

On 26/10/2024 17:08, James Kuyper wrote:
> On 10/26/24 10:07, Vir Campestris wrote:
>> On 22/10/2024 13:48, Thiago Adams wrote:
>>>
>>> I think a more generic feature would be to have a standard way of
>>> promoting selected warnings to errors. This would avoid stacking
>>> features with small differences, such as treating constexpr as a special
>>> case compared to other constant expressions in C.
>>
>> I have in the past had coding standards that require you to fix all
>> warnings. After all, sometimes they do matter.
> 
> I disapprove of that policy. A conforming implementation is free to warn
> about anything, even about your failure to use taboo words as
> identifiers. While that's a deliberately silly example, I've seen a fair
> number of warnings that had little or no justification.
> The purpose of warnings is to tell you that there might be a problem. If
> the compiler is certain that there's a problem, it should generate an
> error message, not a warning. Therefore, treating warnings as if they
> were error messages means that you're not doing your job, as the
> developer, to determine whether or not the code is actually problematic.

I disagree with you here.

But there is an extra condition involved - without it, you have a fair 
point.

The choice of compiler (or linter) warnings needs to be appropriate - it 
needs to be an active decision based on real requirements that are 
appropriate for the kind of coding task and development style in 
question.  If someone things they can use "-Wall -Wextra" and all 
warnings are bugs in the code (or, worse, all bugs in the code lead to 
warnings), then they are not going to get a good development procedure 
by adding "-Werror".  The set of warnings /I/ use for /my/ code are not 
going to match the set that is appropriate for /your/ code - we will 
each have things in our code that the other things is unacceptable as a 
risk of error (now or in future maintenance), compatibility, 
portability, etc.

The compiler warnings also need to be stable.  It is not enough to say 
that we have decided that "-Wall -Wnounused-function 
-Wmaybe-uninitialized" is sufficient for your project and coding 
standards unless you can make fixed requirements on exact compiler 
versions.  Otherwise, using different compilers or versions can change 
the warning set.  (I'm using gcc flags in examples - other compilers 
have other flags.)


When I enable a warning in my builds, it is matching a policy I want for 
the way I write my code - it enforces a restriction in what I can write. 
  For example, I generally use enumerated types for states, and it is 
not uncommon to have a switch statement for dealing with a particular 
state variable.  So I have "-Wswitch-enum" to give a warning if I've 
missed out a possible state.  I make that warning an error.  To me, for 
my code, it is just as much an error in the code if I have added a new 
state to the enumeration but forgotten to handle it somewhere, as if I 
had removed a state from the enumeration but forgotten to remove it from 
the handlers (that would always be a compile-time error).

Good warnings are essential to development.  They are automated checks 
and catch mistakes early.  Of course they don't catch all mistakes, but 
they are part of the process - every tool or development procedure that 
reduces the chances of an error in the final released product is a good 
thing.  Static checks are very low cost, automated, and come early in 
the code-compile-test-release cycle and it is thus much easier and 
cheaper to handle problems found at this point than if they are found 
later on.


So a good set of warnings is useful to have.  But warnings from 
compilers don't stop builds.  If you have a typical build process with a 
makefile (or similar build system) and a bunch of source files, and run 
"make -j", you'll get lots of outputs and your warnings might be hard to 
spot, getting lost in the noise.  Running "make" again won't help - 
files with no errors will not be recompiled, and it will look like your 
build is nice and clean with no problems or warnings.  Thus once your 
project is at a stage in development where you expect to see no or few 
warnings, "-Werror" is key - then you can't miss the warnings.


Of course there will be situations where you'll have false positives - 
warnings about something that you know is correct in your code.  You 
will then have to mark this in your code somehow - it might be a 
slightly different code construct, a compiler-specific attribute, a 
pragma to disable the warning at that particular point (or for that 
whole file).  These are definite actions - you are, in effect, noting 
that this particular piece of code does not clearly comply with your 
coding policies or standards, and needs to be marked as unusual.  (If 
this is happening more than occasionally, then go back to your set of 
warnings and ask if they match the policies you want - or if your 
policies are appropriate in the first place.)