Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Thu, 09 Jan 2025 01:04:27 +0000
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <87r05c4x2c.fsf@bsb.me.uk>
References: <vljvh3$27msl$1@dont-email.me> <20250107130809.661@kylheku.com>
	<vlm0hf$2dkpd$1@dont-email.me> <87a5c15ob0.fsf@bsb.me.uk>
	<vlm7o4$2dkpd$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 09 Jan 2025 02:04:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="903c6fa9911b65ebad208378657cc749";
	logging-data="3193893"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18DecO1J3ixb/o41arNLZwIcxEABuNMPTE="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:2PO8QecDaIHVDXdsbQtvHBwfEBY=
	sha1:BeRsuUHPZmSQRFhj1Q636nqV4ZE=
X-BSB-Auth: 1.0e2eb19678f956a1d3e8.20250109010427GMT.87r05c4x2c.fsf@bsb.me.uk
Bytes: 4778

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.