Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Sat, 30 Nov 2024 09:31:04 -0300
Organization: A noiseless patient Spider
Lines: 142
Message-ID: <vif0i9$1n911$1@dont-email.me>
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> <87iks5sqwo.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 30 Nov 2024 13:31:05 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1ed46619fc8dc497821806c34fcebaea";
	logging-data="1811489"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+E4aDdspfB0SFWGmlf94RV5jRdLPkHA3k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:21mi/m0vgt6u2tk+bMko1xfQYH8=
Content-Language: en-GB
In-Reply-To: <87iks5sqwo.fsf@nosuchdomain.example.com>
Bytes: 5915

Em 11/29/2024 5:53 PM, Keith Thompson escreveu:
> 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).  

Yes. Also compound literal could work like that. E.g
(const int) {1}


It's not always obvious whether an expression is constant or
> not; you have to examine everything it refers to.

I think the compilers will check if the expression is constant anyway.

>  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.
> 

yes.

> 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.

My guess is that compilers checks for constant expressions always even 
for non const. I just checked.

int main() {
   int i = 2147483647 * 2147483647;
}
GCC - warning: integer overflow in expression of type 'int' results in 
'1' [-Woverflow

CLANG - warning: overflow in expression; result is 1 with type 'int' 
[-Winteger-overflow]



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

Yes. But we can avoid it in new code if the same functionally is 
possible with const.

> [...]
> 
>> 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.
> 

The difference for aggregates is that const can be used as constexpr if 
all initializers are constant expressions. (I don´t know what are the 
status of this in C2Y but this is just a logical consequence) While 
constexpr will check if all initializers are constant.

Apart of that I don´t see difference. Both can have storage for instance.

>>
>> (static const struct X ){ }
>>
>> I think in this case it makes sense.
> 
> That's valid in C23.
> 
I known.