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: Tue, 05 Nov 2024 07:46:30 -0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <86wmhhsmy1.fsf@linuxsc.com>
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> <20241027220459.109@kylheku.com> <vfnu92$vp1g$1@dont-email.me> <20241028215919.996@kylheku.com> <vfqjnk$1hos6$1@dont-email.me> <20241029134554.3@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 05 Nov 2024 16:46:37 +0100 (CET)
Injection-Info: dont-email.me; posting-host="22162f0ba694a79b67a6bd5db328b824";
	logging-data="1682490"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Y3bdFtOxOZhOmtIayZrubClzMOAiX4Y0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:ADR/WQKj2RFgwoilSert0p9A+f4=
	sha1:HAIDCueg9E0EwrAPB8ChAcpeJ6o=
Bytes: 2793

Kaz Kylheku <643-408-1753@kylheku.com> writes:

[...]

> "I think truncation does not happen" is here logically equivalent to
> the specific condition that ch is in the range 0 to UCHAR_MAX.
>
> That can be asserted:
>
>   assert (0 <= ch && ch <= UCHAR_MAX);
>
> If ch has the type unsigned char, then this condition is always
> true.
>
> We can think about a warning like that "controlling expression of
> assert unconditionally true due to range of types", but it serves no
> purpose.  There is nothing wrong with asserting something that is
> always true.
>
> When assertions are enabled, the compiler can use their predicates
> to reason about the code and not warn about conditions that are
> precluded by assertions being true.
>
> You will find that this already happens in today's compilers,
> and not due to assert being treated specially.  The assertion
> translates into something like
>
>   if (!(0 <= ch && ch <= UCHAR_MAX)) do {
>     __assert_fail("0 <= ch && ch <= UCHAR_MAX", "foo.c", 42);
>   } while (0)
>
> where __assert_fail is annotated a function which does not return.

Invoking assert() emphatically does not expand into any such
statement.  The C standard requires the assert macro to expand to
a void expression.