Deutsch   English   Français   Italiano  
<44msie3mrn.fsf@be-well.ilk.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lowell Gilbert <lgusenet@be-well.ilk.org>
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Mon, 04 Nov 2024 12:57:16 -0500
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <44msie3mrn.fsf@be-well.ilk.org>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 04 Nov 2024 18:57:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0e760524fb0c36537b88a07cd124e3fe";
	logging-data="1122882"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19yBoND5E9iqO3peh+QabC3"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:S0CIViogNZoGGmErdEqXOd8Ol0I=
	sha1:YqwKCxCXsWOq4c88YTb2df4xfPA=
Bytes: 2949

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.

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.

Be well.
-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/