Re: question about linker

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

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;

We are *defining* the object `i`, which means that the declaration
(which is also a definition) causes storage to be allocated.

But here
>
void f(const struct X * p);
>
We are not declaring the storage for the pointed object.

Right.  But "const" means the same thing: the object `*p` is read-only.
More precisely, the expression `*p` gives us read-only access to that
object; there might be other expressions that give read/write access to
the same object.

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.  If "const" appears in a declaration that
isn't a definition for the object, then the declaration provides a
read-only view of the object (if it exists).  The object itself may or
may not be read-only.

    int n = 42; // read/write
    void func(const int *param); // *param provides a read-only view
    func(&n);
    // The object can be modified via the name "n", but not via
    // the name "*param".

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.

"const storage" is an implementation detail, not part of C semantics.
A conforming implementation could put everything in writable storage
(perhaps the OS doesn't provide memory protection, or the compiler
authors are lazy), relying on C semantics to prevent writes to
const objects.

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.

Sure, you can think of it that way, but it's not what "const"
*means*.  Something like `*(int*)&i = 42;` has undefined behavior,
regardless of the implementation.  If the implementation chooses
to store i in some kind of read-only memory (perhaps enforced by
the OS, perhaps physical RAM), it's likely to crash.  If it stores
it in ordinary read/write memory, it will likely store 42 in i.
Reading i might yield 1 or 42, depending on optimizations (remember
that it's UB).

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;
}
>

There's no fundamental reason an implementation couldn't have
"read-only marked memory" on the stack.

[...]

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.

const and constexpr are two very different things.

Do you have an example where "const means read-only" isn't enough to
understand the C semantics (leaving aside any implementation-specific
choices)?

(But note that given :
    constexpr int n = 42;
`&n` is of type `const int*`.  Which makes sense; we don't want `&n` to
give us write access to n.)

"const" does create a lot of opportunities for optimizations, like
initializing objects at load time rather than during execution.  And a
clever compiler could implement the same optimizations if it's able to
prove that an object is never modified.

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.

I think const, like in here
>
const int i = 1;
>
gives the same guarantee. (The compiler knows the value of i)

That's a very common optimization, but a conforming compiler could
simply read the value stored in `i` on every reference to it.

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.

The fact that constexpr objects still have addresses is perhaps
a bit odd, but that's how C23 defines it.  I like the idea of a
constexpr object with no associated storage, so that

    constexpr int the_answer = 42;

does nothing more than make "the_answer" a name for the value 42,
but C23 doesn't have that.  And I'm not sure it's all that important;
if we never refer to the address of the_answer, the compiler is
free to eliminate its storage.  For most purposes, we can just
ignore the fact that a constexpr object has storage.

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;
     }
   );
}

Without "register", since i is const, its value will never change
(barring undefined behavior), so it should be safe to use anyway.
How is eliminating the storage for i useful?  You can just ignore
it, and the compiler may be able to optimize it away.

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