Re: So You Think You Can Const?

On 08/01/2025 16:16, Ben Bacarisse wrote:

Julio Di Egidio <julio@diegidio.name> writes:

On 07/01/2025 23:11, Kaz Kylheku wrote:

On 2025-01-07, Julio Di Egidio <julio@diegidio.name> wrote:

<snipped>

To the question, I was reading this, but I am not
sure what the quoted passage means:
>
Matt Stancliff, "So You Think You Can Const?",
<https://matt.sh/sytycc>
<< Your compiler, at its discretion, may also choose
      to place any const declarations in read-only storage,
      so if you attempt to hack around the const blocks,
      you could get undefined behavior. >>

>

An object defined with a type that is const-qualified
could be put into write-protected storage.

>
What do you/we mean by "object" in this context?  (Sorry, I do have
forgotten, the glossary to begin with.)

 An object (in C) is a contiguous region of storage, the contents of
which can represent values.

Is that regardless of the stack/heap distinction, or is an "object" about heap-allocated/dynamic memory only?  --  Anyway, I should in fact re-acquaint myself with the language reference instead of asking this question.)

Overall, I am surmising this and only this might go write-protected:
>
   MyStruct_t const T = {...};

 Yes, though you should extend your concern beyond what might be
write-protected.  Modifying an object whose type is const qualified is
undefined, even if the object is in writable storage.

Yes, I am being a bit quick, but I definitely agree with that and indeed the priority of "defined behaviour" as a concern.

While this one allocates a "byte-array", i.e. irrespective of how the
pointer we are assigning it is declared:
>
   MyStruct_t const *pT = malloc(...);
>
Is my understanding (to that point) correct?

 Technically you get an object with no effective type.

OK.

More relevant to a discussion of const is to ask what you plan to do
with pT since you can't (without a cast) assign any useful value to the
allocated object.

Say my program unit implements AVL trees, with (conceptually speaking) constructors/destructors, navigation and retrieval, and of course manipulation (inserting, deleting, etc.).
My idea (but I would think this is pretty "canonical" and, if it isn't, I am missing the mark) is: my public functions take/give "sealed" instances (with const members to const data), as the user is not supposed to directly manipulate/edit the data, OTOH of course my implementation is all about in-place editing...
-Julio