Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Thu, 07 Nov 2024 05:15:13 -0800
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <86o72rrxr2.fsf@linuxsc.com>
References: <veb5fi$3ll7j$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> <vfjcbu$3r4g7$1@dont-email.me> <ExbTO.14733$tnK2.11037@fx04.iad> <86cyjmuoop.fsf@linuxsc.com> <MFuTO.299995$kxD8.185214@fx11.iad> <86r07ru289.fsf@linuxsc.com> <44msie3mrn.fsf@be-well.ilk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 07 Nov 2024 14:15:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f7fe65dae32432817f6ac65ae544dd52";
	logging-data="2815658"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/DXZ20xGA2P/QGHqdROVskUZaSPOKBbMM="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:los9xdQ53sPRn5fk5vjEICCQvTM=
	sha1:sa353GZ9bRx+GZrCa9ZLDcox8Wk=
Bytes: 3469

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Yes, we have a similar policy.  Works well.  In the odd case
>>>>> where one cannot eliminate the warning, a simple compiler option
>>>>> to not test that particulary condition for that particular
>>>>> compilation unit is a straightforward solution.
>>>>
>>>> So the actual policy is to fix all warnings except in
>>>> cases where it's inconvenient to fix them?
>>>
>>> No, I never said that.
>>
>> I didn't say you did.  I asked a question because I didn't see
>> any clear statement of what the policy is that was being
>> followed.  And I still haven't.
>
> Not in so many words, no.  Here is one that I have seen work well
> in recent years:  the code must compile without warnings.  The
> usefulness of this policy is strictly in making sure that any new
> warnings are immediately noticed and considered, but are not an
> ongoing distraction.

You don't say what warning conditions are tested, or who gets to
decide which conditions are included in the set to be satisfied.

> The question of how to shut up a warning that is truly innocuous
> is not part of this policy.  In my own opinion, it will often
> require its own policy.  That is a separate topic, because it can
> quite reasonably vary depending on a number of factors in the
> development environment, most notably the compiler itself.

ISTM that what can be done to remove a warning must be part of
the policy of not allowing warnings.  If there is no statement
about what can be done to remove warnings then the "no-warning"
policy is toothless.  In any case no policy for this aspect is
given, and what I'm looking for is a clear statement of policy.
Was that somehow not obvious from my previous comment?