Re: question about linker

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.