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, 21 Jan 2022 05:30:42 -0800 Organization: A noiseless patient Spider Lines: 45 Message-ID: <86zgnpp665.fsf@linuxsc.com> References: <86tughjjm7.fsf@levado.to> <87czmwosiq.fsf@nosuchdomain.example.com> <874k87q35r.fsf@nosuchdomain.example.com> <875ysmjsfz.fsf@nosuchdomain.example.com> <86pmq47pvb.fsf@linuxsc.com> <86h7bf6vhd.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9bbd2bd2338bc444f9d0c408d9cb7c1c"; logging-data="20633"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18l61BPf52ZdLBP/8BFYGQ8+tZfaBt1SP4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:CdeOt3iAl8nSV6gxo5uqrgnTDb8= sha1:4gMWAqUxfLQkHV5WxtDpSWYoPFQ= Xref: csiph.com comp.lang.c:164503 Bart writes: > On 11/12/2021 14:56, Tim Rentsch wrote: > >> Bart writes: >> >>> On 10/12/2021 09:47, Tim Rentsch wrote: >>> >>>> Manfred writes: >>>> >>>>> On 11/21/2021 9:51 PM, David Brown wrote: >>>>> >>>>>> 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. >>> >>> Well, that is your opinion. >> >> More accurately, it is my belief. >> >>> You haven't really given any of the >>> advantages of having this extra overhead in the allocator that a >>> program may not want or need for any or all of its allocations. >> >> In point of fact, I haven't said anything at all about what is >> needed to implement either kind of allocator interface. >> >> Why don't you write and post code that implements the sort >> of interface you are advocating, so there can be meaningful >> discussion about it? > > It's a big job, and there are many ways of doing it, so I'm not > going to attempt it here. [summary results from a non-C > environment] Yes, as usual you aren't interested in a meaningful discussion. Just the usual bait-and-switch to offtopic.