Sujet : Re: question about linker
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 28. Nov 2024, 10:25:48
Autres entêtes
Organisation : None to speak of
Message-ID : <87plmfu2ub.fsf@nosuchdomain.example.com>
References : 1 2 3
User-Agent : Gnus/5.13 (Gnus v5.13)
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.
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?
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.
[...]
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */