Re: So You Think You Can Const?

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

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?

That's what an object is in all cases.

--  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...

See Tim's reply -- the best way to implement "sealed" instances is to
use an opaque type where the "user code" simply can't see anything but a
pointer to an otherwise unknown struct.

A slight variation to what Tim was suggesting would be to take the
pointer out of the typedef because that can allow you to define an
interface with pointers to const and to non-const AVLtree objects:

  typedef struct AVLtree AVLtree;

  AVLtree *avl_create(void);
  void avl_add(AVLtree *tree, ...);
  void *avl_lookup(const AVLtree *tree, ...);

and so on.  Of course, if you use a more function style as Tim was
suggesting there is no value in having this distinction.

[I must say it's great to have a discussion about C programming for a
change instead of endless threads about how awful C is and how this or
that feature should be added to make it more like Rust/C++/Whatever.]

--
Ben.