Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: on why declare a struct with a single array in it Date: Fri, 10 Dec 2021 01:47:52 -0800 Organization: A noiseless patient Spider Lines: 88 Message-ID: <86pmq47pvb.fsf@linuxsc.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=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="94ee63d76223a75d29f96ac519efdd3f"; logging-data="13838"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gNc1+DQC+yqz1iH74cI+HJMnkGqEYzg8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:RadoPAi/TKgUk5SmMLrur8tfRm4= sha1:A0uowboaRuVf//lNC8Cb2lODbgo= Xref: csiph.com comp.lang.c:163761 Manfred writes: > On 11/21/2021 9:51 PM, David Brown wrote: > >> On 21/11/2021 19:32, Manfred wrote: >> >>> On 11/21/2021 2:51 PM, David Brown wrote: >>> >>>> On 21/11/2021 02:44, Richard Damon wrote: >>>> >>>>> On 11/20/21 7:19 PM, Bart wrote: >>>>> >>>>>> It doesn't make sense. >>>> >>>> I don't want to make a habit of it, but I agree with Bart here :-) >>>> >>>>> Maybe not to you, but I would sure hate to have to keep track of all >>>>> that data, and would likely just wrap this dumb malloc with something >>>>> smarter. >>>> >>>> And that is /fine/. For those few cases where it might be inconvenient >>>> to know the size at deallocation time, make a wrapper so that the size >>>> is tracked. If you need that functionality, write the code and pay the >>>> price - others that don't need the heap to record their allocation sizes >>>> shouldn't have to pay for your needs. It is no different from malloc >>>> and calloc - if you want the convenience of zeroing the memory, you can >>>> use calloc, but if you don't want it you can use malloc and not pay for >>>> the extra effort. >>>> >>>> Of course it is too late to make such untracked-size heap functions the >>>> standard for C - I see it as an unlucky choice made long ago. After >>>> all, if you had "malloc_untracked" and "free_untracked" then it would be >>>> a simple matter to implement traditional C "malloc" and "free" on top >>>> of it. >>> >>> The problem I see with this is that it assumes one and only type of >>> metadata information to be associated to the pointer, specifically the >>> block size. >> >> 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. > > But it means that the implementation has to manage memory blocks based > on size instead of something else - if it had to store anything else > with the pointer, delegating the size to the programmer would be > pointless > One alternative that pops to mind is a pointer to the next block, > however this might work, or nothing at all and a lookup table, or > anything else I couldn't think of right now, since I am not designing > the allocator, which the committee does not design either. > I think it makes sense that the language defines the interface > strictly to fulfill the requirements, and keep as much as possible of > the design internal to the implementation. > > Moreover, the requested size (used by the user) may be different from > the actual size (used by the allocator), which poses some consistency > issues - but that's a side note. > >>> 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. >>> The point is that if you set the interface to be pointer+size you also >>> put constraints on the implementation, on top of the extra burden for >>> the programmer. >> >> How could this suggestion impose any constraints on the implementation? >> The interface for getting the memory is the same (albeit with a >> different name, in order to keep compatibility with existing code), and >> the interface for freeing memory gives the implementation more >> information. It would be perfectly possible (though a little unhelpful) >> for an implementation of the "_untracked" functions to be : >> >> #define malloc_untracked(size) malloc(size) >> #define free_untracked(ptr, size) free(ptr) >> >> An implementation can do better, given this new information, but there >> are no new limitations or restrictions. > > Well, requiring the programmer to keep track of the block size is a > significant programming overhead - if it is unused, it's a significant > waste I'd rather not pay for. Anyone who seriously proposes having to supply a size argument to free memory for a general purpose allocator like malloc() either hasn't bothered to think or doesn't know how to think. Kind of par for the course for the long-running Bart and David show.