Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: So You Think You Can Const? Date: Fri, 10 Jan 2025 10:37:46 -0800 Organization: None to speak of Lines: 59 Message-ID: <87zfjyplad.fsf@nosuchdomain.example.com> References: <874j27qfp7.fsf@nosuchdomain.example.com> <20250110122353.00005377@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 10 Jan 2025 19:37:47 +0100 (CET) Injection-Info: dont-email.me; posting-host="e16be66d43b38b7ea574a81744fe375a"; logging-data="204683"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/o/3n/DwSO29fL6ty8UyIb" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:wqLVZVhsnWiHuEHFFfDORse+Pvw= sha1:FOgeFUHZKjl525VU4Flts6tCmOY= Bytes: 3443 Michael S writes: > On Thu, 09 Jan 2025 23:40:52 -0800 > Keith Thompson wrote: > >> Andrey Tarasevich writes: >> > On 01/09/25 12:12 AM, Julio Di Egidio wrote: >> >> I do not understand that: `free` is changing the pointed data, so >> >> how can `const void *` even be "correct"? >> > >> > `free` is destroying the pointed data. >> >> Right. In other words, it causes the pointed-to data to reach the end >> of its lifetime. "Changing" the data generally means modifying its >> value (that's what "const" forbids). >> >> Given: >> >> int *ptr = malloc(sizeof *ptr); >> *ptr = 42; >> printf("*ptr = %d\n", *ptr); >> free(ptr); >> >> After the call to free(), the int object logically no longer exists. >> Also, the value of the pointer object ptr becomes indeterminate. >> Attempting to refer to the value of either ptr or *ptr has undefined >> behavior. > > I believe that the Standard really says that, but find the part about > value of ptr variable ridiculous. It breaks natural hierarchy by which > standard library is somewhat special, but it is not above rules of core > language. free() is defined as function rather than macro. By rules of > core language, a function call can not modify the value of local > variable at caller's scope, unless pointers to the variable was passed > to it explicitly. Right, the call to free() doesn't change the value of ptr. But that value, which is a valid pointer value before the call, becomes indeterminate after the call. You can even do something like this: int *ptr = malloc(sizeof *ptr); // assume malloc succeeded int *ptr1 = ptr + 1; free(ptr - 1); In most or all actual implementations, referring to the value of ptr after the free() for example with printf("%p", (void*)ptr), won't cause any problems (unless the compiler peforms some optimization based on the assumption that its value won't be accessed). But one can imagine a system that checks pointer values for validity every time they're accessed; on such a system, reading the value of ptr might cause a trap. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */