Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: A defer mechanism for C Date: Thu, 31 Dec 2020 03:34:03 -0800 Organization: A noiseless patient Spider Lines: 67 Message-ID: <86o8iatdjo.fsf@linuxsc.com> References: <3a965b75-7eb6-4287-8e19-8969b6628d90n@googlegroups.com> <81f236a7-76cc-499d-91c1-aff76ea471c2n@googlegroups.com> <87v9cwb4di.fsf@nosuchdomain.example.com> <86y2hjwiec.fsf@linuxsc.com> <87y2hj8323.fsf@nosuchdomain.example.com> <868s9hw1os.fsf@linuxsc.com> <87lfdh8116.fsf@nosuchdomain.example.com> <%RIGH.27563$ay6.6081@fx03.iad> <20201229091749.782@kylheku.com> <878s9g8l29.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="cb646d62786edb6c079bbfa1e5ebfce0"; logging-data="24886"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JDlC1zQ3c1QTFVRrX5cRsU4x0752aIM8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:F4nDNbfZsNfaCdA21LInsWh7jxc= sha1:ZfI3LMBsL2kXCm//2najtGh+IdA= Xref: csiph.com comp.lang.c:157938 Keith Thompson writes: > Kaz Kylheku <563-365-8930@kylheku.com> writes: > >> On 2020-12-29, Richard Damon wrote: >> >>> On 12/29/20 3:33 AM, Keith Thompson wrote: >>> >>>> How, if at all, would the meaning of the standard change if that >>>> sentence: >>>> >>>> The free function causes the space pointed to by ptr to be >>>> deallocated, that is, made available for further allocation. >>>> >>>> were simply deleted? >>>> >>>> I agree that the exact meaning is ambiguous, but I do not believe >>>> that this or any other straightforward sentence in the standard is >>>> merely decorative. >>> >>> Because without that sentence I don't think anything else would ALLOW >>> malloc to reuse the space. >> >> Yes, something would allow that: the fact that the deleted object >> disappeared to the point of any uses of the pointer becoming >> indeterminate behavior. >> >> The above sentence's presence in the standard is downright defective. >> >> It presents a requirement which is not directly testable. > > Yes, it does, but I'm not convinced that's a defect. > >> What is "space"? Suppose we have a vast, 128 bit address space, such >> that malloc always returns a new address. Unused memory is returned to >> the operating system via unmapping it (whenever an unused allocation >> causes one or more VM pages to be completely disused). >> >> Does that implementation fail to return space, because pointer values >> are not recycled? > > Even with a 128-bit address space, if you call free(malloc(1)) > in a loop, you'll *eventually* get, if not the same address, > an address with the same bit representation. On the other hand, > the heat death of the universe is likely to happen first. > > I suggest that there needs to be *something* in the standard that > says that free() does something useful beyond making the address > indeterminate. I *should* be able to call malloc and free in a > loop and not worry about resource exhaustion. I don't necessarily agree that this guarantee should apply to every implementation (in some category), but even if it should the C standard is not the right place to express it. > Given the variations > in permissible memory management schemes (and we *want* to permit > wide variations), I can't think of a better way to express that > than what the standard says now. > > But I could probably get behind the idea that it should be a note > rather than normative text. > > There's no (explicit) meta-requirement that all requirements in the > standard need to be directly testable. Should there be? No, because it isn't practical.