Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Sun, 12 Jan 2025 22:38:32 -0800
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <86frln6wwn.fsf@linuxsc.com>
References: <vljvh3$27msl$1@dont-email.me> <vlma9m$2s5e5$1@dont-email.me> <vlo0cm$2dkpd$9@dont-email.me> <vlqd4j$3s4ai$1@dont-email.me> <20250110103252.718@kylheku.com> <vlu6qh$miie$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 13 Jan 2025 07:38:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9eea8443f476a77794ac96904ee9ae64";
	logging-data="1778439"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18hmgrvmpScslVhtSAWBIXk7H1WCYIkWjc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:e/nViVqao2K4e38Ejy+D4B86TfU=
	sha1:Fy0me64aTZH4I1szBK8CClo4AHc=
Bytes: 3858

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 01/10/25 10:37 AM, Kaz Kylheku wrote:
>
>> Destruction by malloc is modifying in any system that recycles the
>> memory for another allocation.
>
> From such a radically "physical" point of view, nothing is and nothing
> will ever be `const`... Sorry, this is not even close to what
> "constness" in C is about.
>
> In C and C++ (as well in virtually all higher level languages)
> "constness" is not a physical concept.  It is a purely high-level
> logic-level concept, designed, implemented and enforced entirely by
> the author of the code (of the public interface of the module) in
> accordance with their intent.
>
> It has absolutely no relation to any physical modifications that might
> occur anywhere in the execution environment.  Nobody cares whether
> something somewhere gets "modified".  It is always a question of
> whether _I_ want to recognize such modifications as part of the public
> interface designed by me.  I'm the one who says whether the operation
> is "constant" or not, based purely on my idea of "logical constness".
>
> That's the reason `const` exists in C (and C++).
>
> However (returning to the more narrowly focused matter at hand), two
> things - creation and deletion of objects - will always indisputably
> stand apart as operations that transcend/defeat/ignore the idea of
> "constness" with relation to the object itself.  Creation/deletion
> might logically be seen as "non-constant" wrt to the surrounding
> environment (e.g. memory manager), but wrt to the object itself they
> shall not (and, obviously, cannot) care about its "constness" at all.
>
> An object begins being `const` only after the process of its creation
> (construction) is complete.  [...]

This idea doesn't match how C semantics works.  In particular, an
object in C can be "created" (start its lifetime) before it is
"constructed" (initialized).  Consider the following code:

    #include <stdio.h>

    int
    main(){
        int i = 0;
        const int *p;
        {
          MORE:
            if(  i > 0  )  printf( "  i, *p :  %2d %2d\n", i, *p  );
            const int j = i+7;
            p = &j;
            i++;
            if(  i < 10  )  goto MORE;
        }
        return  0;
    }

The object for j comes into existence once when the inner compound
statement is entered, but it is initialized 10 times.  The access
to j through *p has well-defined behavior.  The initializing
declaration for j (which is also a definition) does not modify the
value of j, in the sense that the C standard uses the term, but
only initializes j, even though the same object is being
initialized over and over.