Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Fri, 29 Nov 2024 12:53:27 -0800
Organization: None to speak of
Lines: 103
Message-ID: <87iks5sqwo.fsf@nosuchdomain.example.com>
References: <vi54e9$3ie0o$1@dont-email.me> <vi6sb1$148h7$1@paganini.bofh.team>
	<vi6uaj$3ve13$2@dont-email.me>
	<87plmfu2ub.fsf@nosuchdomain.example.com>
	<vi9jk4$gse4$1@dont-email.me>
	<87bjxzt7xq.fsf@nosuchdomain.example.com>
	<vicc5d$12kql$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Nov 2024 21:53:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f64fae3639db49189bd8f4bb24b9887f";
	logging-data="1300414"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187NLajNLkLY6E8sVQzFl2t"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:W0/sCuBXAAuRXdlWh8hDidt2xMA=
	sha1:X+CZ6zkZxQQ3DkBxSflufTRSLZ8=
Bytes: 4860

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 11/28/2024 5:33 PM, Keith Thompson escreveu:
>> If an object is const because of its definition, then that object is
>> itself read-only, and anything that bypasses that (pointer casts, etc.)
>> causes undefined behavior.
>
> Yes. This is my point. When the object itself cannot change, I used
> the name immutable. And "ready only" when we don´t know if the object
> is immutable or not - like pointer to const object.
> In any, case it is just a matter of definition. I think it is clear
> for both of us. (I am not claiming these definitions are part of C
> standard)
>
>>> For compile that computation what matters is the guarantee that the
>>> compiler knows the values (it knows because it always the same value
>>> of initialization) when using the object. (It does not depend on flow
>>> analysis)
>> There's no requirement for the compiler to "know" the value of a const
>> object.
>
> When the expression is required to be constant expression like in
> switch case, then the compiler must know the value.

True, but we weren't talking about constant expressions.  We were
talking about objects of const type.  Despite the obvious similarity of
the words "const" and "constant", they're really two different things.

And the name of an object (in the absence of constexpr) can't be a
constant expression.  Given `const int zero = 0;`, the name `zero` is
not a constant expression and cannot be used in a case label.  (There
are proposals to change that.)

> Sorry if I am begin repetitive, but here is my motivation to say that
> const was already ready for that, no need to new keyword constexpr.
>
> Consider this sample
>
> void f(const int a)
> {
>   const int b = 1;
>
>   switch (a){
>      case a: break; // OPS
>      case b: break; // should be OK
>   }
> }
>
> The compiler does not know the value of 'a' even it is declared as
> constant object; on the other hand the compiler knows the value of
> 'b';
>
> So, here is my point - In init-declarators. const and constexpr
> becomes similar.

That has been proposed, but I personally oppose it, and the language (as
of C23) doesn't support it.  (C++ does.)

Given:

    const int b = initializer;

the expression `b` would be a constant expression if and only if the
initializer is a constant expression (optionally enclosed in {...}, I
suppose).  It's not always obvious whether an expression is constant or
not; you have to examine everything it refers to.  And if you intend b
to be a constant expression but accidentally write a non-constant
initializer, it's still a perfectly valid declaration of a read-only
object initialized with the result of evaluating a run-time expression;
the error won't be flagged until you try to use it.

Recall that `const int r = rand();` is still perfectly valid.

But given:

    constexpr int b = initializer;

you *know* that b can be used as a constant expression, and if the
initializer is not constant the compiler will flag it immediately.

This is already in C23.  Dropping constexpr is politically impossible at
this point.

[...]

> C23 also added constexpr in compound literal.
>
> (constexpr struct X ){ }
>
> I also don´t understand why not just use const for that.

Because constexpr and const mean different things.

> I also allow static.
>
> (static const struct X ){ }
>
> I think in this case it makes sense.

That's valid in C23.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */