Manfred <noname@add.invalid> 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.

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. 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.

For example, some programs may never need to free memory until they
terminate.

On Monday, 22 November 2021 at 10:31:52 UTC, David Brown wrote:
>
> And can you give examples of where you have a pointer to a block of
> memory but do not know the size of the memory?
>
The only example I can think of is where you are passed a compressed
data stream, and the "end of data" marker is retrieved as part of the
decompression.
However normally you would pass about a "memory size" parameter
anyway, just to guard against truncated data.

On 10/12/2021 13:21, Malcolm McLean wrote:
> On Monday, 22 November 2021 at 10:31:52 UTC, David Brown wrote:
>>
>> And can you give examples of where you have a pointer to a block of
>> memory but do not know the size of the memory?
>>
> The only example I can think of is where you are passed a compressed
> data stream, and the "end of data" marker is retrieved as part of the
> decompression.

Fair enough - that's a reasonable example.

> However normally you would pass about a "memory size" parameter
> anyway, just to guard against truncated data.
>

Indeed.

And whichever part of the code is responsible for allocating the memory,
knows the size of the buffer. I think it is not unreasonable for this
size to be communicated to whatever part of the code is responsible for
deallocating the memory (which may or may not be the bit that does the
decompressing).

On 10/12/2021 11:55, Bart wrote:
> 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. 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.

Remember, this is Tim posting. It's just another drive-by
shot-the-messenger (and perhaps innocent bystanders) post, coming along
weeks after most people have forgotten about the thread. If you are
lucky, you'll get a reply containing nothing but sarcasm, cryptic
messages, and patronising insults sometime next year.

He used to post interesting things, and had insights into details of C
and the standards that most others missed. Maybe he still could, but he
sees to prefer to play the grumpy old man and wave his Zimmer frame at
people who disturb his slumber.

(And yes, I know he'll ignore this post. He has burned that bridge, and
many others, long ago.)

>
> For example, some programs may never need to free memory until they
> terminate.
>
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> 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.

Tim, it's sad to see this kind of crap from you. I remember when you
had interesting things to say here.

--
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 */

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?

On 11/12/2021 14:56, Tim Rentsch wrote:
> 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?

It's a big job, and there are many ways of doing it, so I'm not going to
attempt it here.

Basically, instead of free(p), you might typically write newfree(p,
size(*p)) instead, when p points to an object where the compiler knows
the size (eg. to a struct). Otherwise you need to keep track of it.

The only such implementation I have is part of my language's runtime,
and was optimised for interpreters. It uses special allocators for
objects up to 2KB, using pools obtained with malloc, and calls malloc
directly (but with sizes pre-rounded to my own prefered limits) for
larger blocks.

And it is not in C. If I use a generated-C version of it and apply it to
the Binary Trees benchmark, then it is 4 times as fast as using plain
malloc/free using Windows/msvcrt, and about 2.5 times as fast under WSL.

Regular version using malloc+free:

https://github.com/sal55/langs/blob/master/binary.c

Version using my allocator for tree nodes (note lots of ugly generated C
code; this is not up for discussion, only the results):

https://github.com/sal55/langs/blob/master/binary2.c

(Benchmark code starts line 194; it differs on two lines from the other
version: using pc_alloc for malloc, and pc_free for free.)

On 11/12/2021 16:04, Bart wrote:
> On 11/12/2021 14:56, Tim Rentsch wrote:
>> 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?
>
> It's a big job, and there are many ways of doing it, so I'm not going to
> attempt it here.
>
> Basically, instead of free(p), you might typically write newfree(p,
> size(*p)) instead, when p points to an object where the compiler knows
> the size (eg. to a struct). Otherwise you need to keep track of it.
>
> The only such implementation I have is part of my language's runtime,
> and was optimised for interpreters. It uses special allocators for
> objects up to 2KB, using pools obtained with malloc, and calls malloc
> directly (but with sizes pre-rounded to my own prefered limits) for
> larger blocks.
>
> And it is not in C. If I use a generated-C version of it and apply it to
> the Binary Trees benchmark, then it is 4 times as fast as using plain
> malloc/free using Windows/msvcrt, and about 2.5 times as fast under WSL.
>
>
> Regular version using malloc+free:
>
> https://github.com/sal55/langs/blob/master/binary.c
>
> Version using my allocator for tree nodes (note lots of ugly generated C
> code; this is not up for discussion, only the results):
>
> https://github.com/sal55/langs/blob/master/binary2.c

[Note needs 64-bit target]

> (Benchmark code starts line 194; it differs on two lines from the other
> version: using pc_alloc for malloc, and pc_free for free.)

Note that for this benchmark, the size of the 'treenode' struct, 20
bytes [on x64] is rounded up to 32 bytes for both allocators (in the
case of malloc, the extra space is likely used for the size as well as
for alignment).

So both use the same amount of memory.

If I increase the struct to 32 bytes in the user program, then malloc
will I think use 48 bytes per allocation; pc_alloc still uses 32 bytes.

On Windows that doesn't make much difference (I don't know the maximum
memory in use, maybe it's not that high).

On WSL however, it makes the malloc-based version 20% slower, so taking
3 times as long as the pc_alloc version.

On 12/11/2021 6:56 AM, Tim Rentsch wrote:
> 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.

I am quite fond of the reap interface:

https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

>
> 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?
>

In article <86h7bf6vhd.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
....
>> Well, that is your opinion.

>More accurately, it is my belief.

There is no difference between an opinion and a belief.

The two words are virtually synonymous.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seriously

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <86h7bf6vhd.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> ...
>
>>> Well, that is your opinion.
>>
>> More accurately, it is my belief.
>
> There is no difference between an opinion and a belief.

There is in the way that I use these two words.

In article <861r2h7pu4.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> ...
>>
>>>> Well, that is your opinion.
>>>
>>> More accurately, it is my belief.
>>
>> There is no difference between an opinion and a belief.
>
>There is in the way that I use these two words.

Give me an example of how you could have an opinion about something and not
have it be your belief.

And/or vice versa.

--
You are again heaping damnation upon your own head by your statements.

- Rick C Hodgin -

On 12/12/21 12:38 PM, Kenny McCormack wrote:
> In article <861r2h7pu4.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> ...
>>>
>>>>> Well, that is your opinion.
>>>>
>>>> More accurately, it is my belief.
>>>
>>> There is no difference between an opinion and a belief.
>>
>> There is in the way that I use these two words.
>
> Give me an example of how you could have an opinion about something and not
> have it be your belief.
>
> And/or vice versa.
>
There's a difference in how most people use the words.

In article <sp5p0u$l4g$1@dont-email.me>, Dick <thiebauddick2@aol.com> wrote:
>On 12/12/21 12:38 PM, Kenny McCormack wrote:
>> In article <861r2h7pu4.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>
>>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>> ...
>>>>
>>>>>> Well, that is your opinion.
>>>>>
>>>>> More accurately, it is my belief.
>>>>
>>>> There is no difference between an opinion and a belief.
>>>
>>> There is in the way that I use these two words.
>>
>> Give me an example of how you could have an opinion about something and not
>> have it be your belief.
>>
>> And/or vice versa.
>>
>There's a difference in how most people use the words.

But, nobody can say what that difference is...

Anyway, I say otherwise, but for reasons beyond the scope of this post.

--
Elect a clown, expect a circus.

On 12/12/2021 22:19, Dick wrote:
> On 12/12/21 12:38 PM, Kenny McCormack wrote:
>> In article <861r2h7pu4.fsf@linuxsc.com>,
>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>
>>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>>> ...
>>>>
>>>>>> Well, that is your opinion.
>>>>>
>>>>> More accurately, it is my belief.
>>>>
>>>> There is no difference between an opinion and a belief.
>>>
>>> There is in the way that I use these two words.
>>
>> Give me an example of how you could have an opinion about something
>> and not
>> have it be your belief.
>>
>> And/or vice versa.
>>
> There's a difference in how most people use the words.

The more relevant point would be how Tim differentiates between the
words. Clearly it was important to him. Equally clearly, people have
subtly different ideas about what the words mean to /them/, and whether
there is a significant difference between them. (There is,
unfortunately, no standards document for the English language.)

If Tim wants more people to appreciate what exactly he meant, then he'll
have to elaborate. If he doesn't care about what others think (and my
guess is that Kenny was added to Tim's naughty list long before I was),
he'll not bother.

On Monday, 13 December 2021 at 08:06:37 UTC, Kenny McCormack wrote:
> In article <sp5p0u$l4g$1...@dont-email.me>, Dick <thieba...@aol.com> wrote:
> >On 12/12/21 12:38 PM, Kenny McCormack wrote:
> >> In article <861r2h7...@linuxsc.com>,
> >> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> >>> gaz...@shell.xmission.com (Kenny McCormack) writes:
> >>>
> >>>> In article <86h7bf6...@linuxsc.com>,
> >>>> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> >>>> ...
> >>>>
> >>>>>> Well, that is your opinion.
> >>>>>
> >>>>> More accurately, it is my belief.
> >>>>
> >>>> There is no difference between an opinion and a belief.
> >>>
> >>> There is in the way that I use these two words.
> >>
> >> Give me an example of how you could have an opinion about something and not
> >> have it be your belief.
> >>
> >> And/or vice versa.
> >>
> >There's a difference in how most people use the words.
> But, nobody can say what that difference is...
>
> Anyway, I say otherwise, but for reasons beyond the scope of this post.
>
You don't get exact synonyms in a natural language. One form always acquires
certain overtones that the other lacks. It may be archaic, or associated with a
different dialect, or it might have a subtle shade of meaning.

"Opinions" are less serious, less stable and deep seated than beliefs. So
"his Buddhist beliefs" but not "his Buddhist opinions", unless you wish to question
the seriousness of someone's Buddhism.

Dick wrote:
>>>>>> Well, that is your opinion.
>>>>>
>>>>> More accurately, it is my belief.
>>>>
>>>> There is no difference between an opinion and a belief.
>>>
>>> There is in the way that I use these two words.
>>
>> Give me an example of how you could have an opinion about something and not
>> have it be your belief.
>>
>> And/or vice versa.
>>
> There's a difference in how most people use the words.

Is that your opinion or your belief?

In article <j1pj4fFq3mbU3@mid.individual.net>,
Robert Latest <boblatest@yahoo.com> wrote:
>Dick wrote:
>>>>>>> Well, that is your opinion.
>>>>>>
>>>>>> More accurately, it is my belief.
>>>>>
>>>>> There is no difference between an opinion and a belief.
>>>>
>>>> There is in the way that I use these two words.
>>>
>>> Give me an example of how you could have an opinion about something and not
>>> have it be your belief.
>>>
>>> And/or vice versa.
>>>
>> There's a difference in how most people use the words.
>
>Is that your opinion or your belief?

Apparently, both.

And that's basically my point.

Anyway, and for what it's worth, I basically reserve the word "belief" for
matters of religion (where, by religion, I actually mean any situation
where people believe a thing with no evidence). Anything else is an
opinion.

And, in terms of the words, I would use, I would usually say "Well, I think
that ...". Very rarely, would I say "I believe that ..." (unless I was in
the area of religion).

--
The last time a Republican cared about you, you were a fetus.

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <861r2h7pu4.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> ...
>>>
>>>>> Well, that is your opinion.
>>>>
>>>> More accurately, it is my belief.
>>>
>>> There is no difference between an opinion and a belief.
>>
>> There is in the way that I use these two words.
>
> Give me an example of how you could have an opinion about
> something and not have it be your belief.
>
> And/or vice versa.

Don't you think it would be better first to try to find out the
sense in which I mean the two words, rather than steering the
discussion towards a pointless and futile argument?

In article <86v8zq460v.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> In article <861r2h7pu4.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>
>>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>> ...
>>>>
>>>>>> Well, that is your opinion.
>>>>>
>>>>> More accurately, it is my belief.
>>>>
>>>> There is no difference between an opinion and a belief.
>>>
>>> There is in the way that I use these two words.
>>
>> Give me an example of how you could have an opinion about
>> something and not have it be your belief.
>>
>> And/or vice versa.
>
>Don't you think it would be better first to try to find out the
>sense in which I mean the two words, rather than steering the
>discussion towards a pointless and futile argument?

I have been doing exactly that - trying to get you to explain how, in your
terms, the words differ in meaning.

My own view is that while the words are effectively synonyms, people tend
to use each of them in different contexts. As I said earlier, to me, a
"belief" is an opinion not backed by evidence. Usually, these "beliefs"
are in the general area of religion - you know, virgin births, talking
snakes, 6Kyo Earth, etc.

--
To be evangelical is to spend every waking moment hovering around
two emotional states: fear and rage. Evangelicals are seriously the
angriest and most vicious bunch of self-pitying, constantly-moaning
whinybutts I've ever encountered.

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <86v8zq460v.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>> In article <861r2h7pu4.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>>
>>>>> In article <86h7bf6vhd.fsf@linuxsc.com>,
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>> ...
>>>>>
>>>>>>> Well, that is your opinion.
>>>>>>
>>>>>> More accurately, it is my belief.
>>>>>
>>>>> There is no difference between an opinion and a belief.
>>>>
>>>> There is in the way that I use these two words.
>>>
>>> Give me an example of how you could have an opinion about
>>> something and not have it be your belief.
>>>
>>> And/or vice versa.
>>
>> Don't you think it would be better first to try to find out the
>> sense in which I mean the two words, rather than steering the
>> discussion towards a pointless and futile argument?
>
> I have been doing exactly that - trying to get you to explain how,
> in your terms, the words differ in meaning.

Ahh. In that case, I believe that every even number greater than
two is the sum of two primes.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Don't you think it would be better first to try to find out the
> sense in which I mean the two words, rather than steering the
> discussion towards a pointless and futile argument?

No, because you've passed up numerous opportunities to explain what
you mean. If you had wanted to avoid "a pointless and futile
argument", you could have done so easily.

--
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 */

Bart <bc@freeuk.com> writes:

> On 11/12/2021 14:56, Tim Rentsch wrote:
>
>> 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?
>
> 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.

On 21/01/2022 13:30, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 11/12/2021 14:56, Tim Rentsch wrote:
>>
>>> 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?
>>
>> 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.

WTF?

You asked me to write and post code, and I wrote and posted code, and IN
C. (Which, since it was 6 weeks ago, has now been removed in a periodic
clean-up.)

What exactly did you want, a completed, production-ready memory
allocation scheme? The scheme I demonstrated was one I was already using
myself, and I show that it gave significant improvements over regular
malloc/free.

I notice you didn't post any code..

And what topic did I switch to? The sub-topic was memory allocators, and
my code demonstrated an allocator using caller-retained size into to
signicantly improve an allocation benchmark.

You're a fucking idiot.