Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: on why declare a struct with a single array in it
Date: Sat, 11 Dec 2021 06:56:30 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <86h7bf6vhd.fsf@linuxsc.com>
References: <86tughjjm7.fsf@levado.to> <smmhhg$bfh$1@dont-email.me> <sn5pcl$pru$1@dont-email.me> <sn5qji$3ri$1@dont-email.me> <sn5rc0$1i81$1@gioia.aioe.org> <sn5ukn$2ir$1@dont-email.me> <sn6iam$n5t$1@dont-email.me> <sn8kq9$tep$1@gioia.aioe.org> <87czmwosiq.fsf@nosuchdomain.example.com> <Y2UlJ.79170$ya3.75666@fx38.iad> <874k87q35r.fsf@nosuchdomain.example.com> <snaq53$voh$1@dont-email.me> <875ysmjsfz.fsf@nosuchdomain.example.com> <snc3a0$6gs$1@dont-email.me> <KvhmJ.55056$np6.2360@fx46.iad> <snditr$7l1$1@dont-email.me> <sne3b7$1mre$1@gioia.aioe.org> <snebg4$jtk$1@dont-email.me> <sneuje$1qm$1@gioia.aioe.org> <86pmq47pvb.fsf@linuxsc.com> <sovbmf$b13$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="601297b613a158a006ae67e40d920115"; logging-data="5373"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/kyQ6pTYWS4mZTUPF0f3I9Uuj/ePArozE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:vI3n09o6eyXeNmcKnn4bKtOWqo0= sha1:7jF58rbatY2cGhMriZ3kkpVGhYs=
Xref: csiph.com comp.lang.c:163786

Bart <bc@freeuk.com> writes:

> On 10/12/2021 09:47, Tim Rentsch wrote:
>
>> Manfred <noname@add.invalid> 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?