Re: question about linker

On 28/11/2024 06:25, Keith Thompson wrote:

Thiago Adams <thiago.adams@gmail.com> writes:

On 27/11/2024 07:29, Waldek Hebisch wrote:

[...]

1) campilers for embedded targets care very much about const.  const
     qualified arrays go into read-only data section which is typically
     located in flash.  Other arrays go to RAM.  Embedded targets
     frequently have very small RAM and larger flash, so after
     dropping const program may no longer fit in available RAM.

>
I think your comment applies for const in declarations like
>
const int i = 1;
>
I used to find const confusing, as it sometimes meant 'read-only' and
other times 'immutable.'

 I'm not sure what you mean.  My understanding is that const means
read-only, and nothing else.

I think my previous comment is not precise; it could be better phrased. It also have some mistakes about init-declarator.
I will give samples what I was trying to say.
When we have this declaration we are declaring some storage (for the i variable)
const int i = 0;
But here
void f(const struct X * p);
We are not declaring the storage for the pointed object.
So, for the first case, we can think const as declaring a immutable storage, while for the second sample const acts as "read-only" - we don't know if the storage is const or not.

Now, it seems less confusing to me. When const is used with variables
that can be initialized (init-declarator), it acts as 'immutable',
meaning the storage is constant.

 What exactly do you mean by "the storage is constant"?  Are you talking
about memory that is marked as read-only by the OS?

Here comes another point (that I realized after I wrote that) and that makes const more confusing.
When const is used in a external declaration like
const int i = 1;
int main(){}
We can think about read-only marked memory.
But for local variables it does not make sense to have "read-only marked memory" because it lives on stack.
int main(){
   const int i = 1;
}

Given something like:
      const int r = rand();
 at block scope, the object will almost certainly be stored in ordinary
read/write memory.  The compiler will flag code that attempts to modify
it (unless you play tricks with pointer casts, which can introduce
undefined behavior).  But if I do something like `*(int*)&r = 42;`,
it's likely to "work".
 Defining an object as const can *enable* a compiler to store it in
read-only memory (enforced by the OS, or maybe even physical RAM on some
systems), but that's an implementation choice, not part of the semantics
of const.
 [...]
 

Yes, you have pointed out, what I realized after writing this.Thanks for paying attention into these details
const is very context dependent, maybe trying to reuse the same keyword, and I think C23 had a change to clarify it, but instead make it more confusing with constexpr, that was the point of my previous topic.
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)
I think const, like in here
const int i = 1;
gives the same guarantee. (The compiler knows the value of i)
What I think could be explored more is the usage of register keyword as meaning "no-storage".
The idea of const no-storage is good because it eliminates any problem with object lifetime and it makes the perfect constants in my view. Unfortunately, constexpr does not mean that because we can take the address of constexpr object.
Sample why no-storage is useful
void F()
{
    register const int i = 1;
    //lets way we have lanbdas in C
    f( []()
      {
          //safe to use i even in another thread, or even after exiting F
          int k = i;
      }
    );
}