Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: on why declare a struct with a single array in it Date: Mon, 22 Nov 2021 13:00:33 -0800 Organization: None to speak of Lines: 44 Message-ID: <87ee77j47i.fsf@nosuchdomain.example.com> References: <86tughjjm7.fsf@levado.to> <87pmr5qih6.fsf@bsb.me.uk> <87czmwosiq.fsf@nosuchdomain.example.com> <874k87q35r.fsf@nosuchdomain.example.com> <875ysmjsfz.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="58c43985092162f95fdbb2eb9dbfb717"; logging-data="8872"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lLi7JCx/sEffFPHW2eiu7" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:7UyRGrAcZwH8moIMZ/rDl0o+yKc= sha1:odTOh6gwQ2Goph3rpGYW6bna4jg= Xref: csiph.com comp.lang.c:163573 Bart writes: > On 22/11/2021 03:06, Guillaume wrote: >> Le 21/11/2021 à 21:51, David Brown a écrit : >>> No.  It merely relieves the heap implementation from having to store the >>> size of the allocation.  Any other metadata (such as for tracking free >>> space lists, or handling efficient multi-threaded access) will still be >>> needed. >>> >>>> I believe there are countless implementations of malloc out there, and I >>>> guess this might not be the case, or it may be the case today but not >>>> tomorrow. >> >> Of all the typical implementations of malloc() and similar >> general-purpose allocators, I've always seen the same approach of >> storing metadata either right before (with then the appropriate >> padding if required), or right after the actual usable block of >> memory. In a number of cases, the metadata is even duplicated both >> before and after the block - for data locality reasons. This can be >> more efficient cache-wise. > > Have you considered the reason why such implementations need to store > such metadata at all? > > Namely, because the specification says that malloc must record the > size simply so that free() will know what it is! There's no explicit requirement for free() to know the size of the record being deallocated. It likely will in most implementations, but I can imagine an implementation where deallocation doesn't require knowing the size. One example: malloc() may allocate more size than was asked for, and remember only the actual allocated size, not the requested size. Or the allocated size might change after allocation if a following block is freed. (But realloc() does make it convenient to have some idea of what was requested.) Or malloc() and free() might be implemented on top of some lower level interface that doesn't expose that information. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */