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: Thu, 28 Nov 2024 08:19:32 -0300
Organization: A noiseless patient Spider
Lines: 138
Message-ID: <vi9jk4$gse4$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Nov 2024 12:19:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2918acb05f51d937a038340d9b09ba9b";
	logging-data="553412"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18fzmIwhSD1zZfsRTKuYK4i4Bm8vv6L++8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6GTKhewn//vz6ebpC9NaOczDjrY=
Content-Language: en-US
In-Reply-To: <87plmfu2ub.fsf@nosuchdomain.example.com>
Bytes: 5133

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