On Wed, 27 Nov 2024 01:39:34 -0500, 186282@ud0s4.net wrote:

> On 11/25/24 4:49 PM, Lawrence D'Oliveiro wrote:
>
>> There is a “new BASIC” that fits that description: it’s PHP.
>
> Ummmmmm ... CAN use it for general programming ... but it's not
> super-pleasant :-)

It attracts the kind of people who might have used BASIC before.

> Python is "better" - but not THAT much better.

It’s a whole lot better. Nearly all of the language features are very
carefully thought out. The result is that the core remains compact, yet is
versatile, which is why you get so many library modules built on top of it
-- because the language makes such modules very powerful.

On 11/27/24 22:06, Lawrence D'Oliveiro wrote:
> On Wed, 27 Nov 2024 09:27:35 +0000, Pancho wrote:
>
>> I remember we ran a tool
>> called Purify to spot this type of error, amongst other errors.
>> Presumably that injected additional code to check reliably.
>
> As I understand it, Valgrind does it on your executable without source
> code changes.

Yeah, It was 30 years ago, I think Purify modified binary code, not
source code, but I can't really remember. I just remember Purify was
brilliant..

The proper term is "instrumentation".

<https://en.wikipedia.org/wiki/Instrumentation_(computer_programming)>

I note Valgrind Memcheck inserts instrumentation too.

Development standards have improved, languages are much better now, but
back then we really needed help. Our main problem was memory leaks, we
had to regularly restart servers.

We also used similar tools to provide data on program performance,
profiling.

On Wed, 27 Nov 2024 23:59:36 +0000, Pancho wrote:

> On 11/27/24 22:06, Lawrence D'Oliveiro wrote:
>> On Wed, 27 Nov 2024 09:27:35 +0000, Pancho wrote:
>>
>>> I remember we ran a tool called Purify to spot this type of error,
>>> amongst other errors.
>>> Presumably that injected additional code to check reliably.
>>
>> As I understand it, Valgrind does it on your executable without source
>> code changes.
>
> Yeah, It was 30 years ago, I think Purify modified binary code, not
> source code, but I can't really remember. I just remember Purify was
> brilliant..

I don't know if I would call it brilliant. We had a license for a while
but didn't renew it since it was seldom used due to the complexity of
setting up the instrumentation. I'd used BoundsChecker years ago and it
was no prize either.

On 11/27/24 5:13 PM, Lawrence D'Oliveiro wrote:
> On Wed, 27 Nov 2024 01:39:34 -0500, 186282@ud0s4.net wrote:
>
>> On 11/25/24 4:49 PM, Lawrence D'Oliveiro wrote:
>>
>>> There is a “new BASIC” that fits that description: it’s PHP.
>>
>> Ummmmmm ... CAN use it for general programming ... but it's not
>> super-pleasant :-)
>
> It attracts the kind of people who might have used BASIC before.

I never really saw it as so "BASIC-like" ...

To me the look&feel is kinda like a mix of tiny 'C',
Bash and a bit of Java.

In any case, best suited for web pages. That is
its natural environment. I've writ some web
stuff with kinda a lot of PHP in them. The most
fun spawned a TEMPORARY mirror of the site in
a TEMPORARY subdir that'd expire after 15 minutes
of non-use. That way there was no permanent link
hacks could keep attacking. The mother site was
kept entirely off the webroot.

Anyway, WordPress and Joomla and most anything
else for the web is REALLY stupid and useless
without PHP.

>> Python is "better" - but not THAT much better.
>
> It’s a whole lot better. Nearly all of the language features are very
> carefully thought out. The result is that the core remains compact, yet is
> versatile, which is why you get so many library modules built on top of it
> -- because the language makes such modules very powerful.

IMHO, 'C' and Pascal are The Best. Python is 'fair', and
has become a little more fair over time.

Other opinions will vary.

These days you'll get the Rust crusaders :-)

On 11/27/24 4:12 AM, D wrote:
>
>
> On Wed, 27 Nov 2024, 186282@ud0s4.net wrote:
>
>> On 11/26/24 4:12 AM, D wrote:
>>>
>>>
>>> On Mon, 25 Nov 2024, 186282@ud0s4.net wrote:
>>>
>>>> On 11/25/24 4:56 AM, D wrote:
>>>>>
>>>>>
>>>>> On Mon, 25 Nov 2024, 186282@ud0s4.net wrote:
>>>>>
>>>>>> On 11/24/24 7:36 PM, Lawrence D'Oliveiro wrote:
>>>>>>> On Sun, 24 Nov 2024 19:35:57 -0500, 186282@ud0s4.net wrote:
>>>>>>>
>>>>>>>> Do kinda pref "{ }" or "begin end" over the dangling depth thing
>>>>>>>> ...
>>>>>>>> get six or eight levels into something and it's a total bitch to
>>>>>>>> spot
>>>>>>>> what's inside what without using comments.
>>>>>>>
>>>>>>> So use the comments. That’s what I do.
>>>>>>
>>>>>>  Only good way ...
>>>>>>
>>>>>>  Not a killer, but kinda annoying. The eye doesn't
>>>>>>  spot indents nearly was well as hard delimiters.
>>>>>>
>>>>>
>>>>> You can have indents _and_ delimiters for the ultimate in eye
>>>>> spotting capability! ;)
>>>>
>>>>  As I said to Larry, I almost always use just 2-space
>>>>  indents so deeply-nested stuff doesn't tend to run
>>>>  off the page margin. Object langs make this even worse
>>>>  with all the something.something.something.something
>>>>  sorts of lines.
>>>>
>>>>  SOME of the IDEs for Python KINDA help, can spot
>>>>  nestings fairly well, but I mostly just use nano
>>>>  in one terminal and do test runs from another.
>>>>  Something like PyCharm or Visual are kinda overkill
>>>>  most of the time.
>>>>
>>>
>>> I use four, but since worked as a systems administrator (or what
>>> today be called "devops") I never wrote any programs large enough, or
>>> complicated enough, to run out of line space.
>>
>>  My last big Python app was about 450 lines of code - and
>>  it had LOTS of option switches (TOO many!). Things got
>>  nested really deep sometimes.
>>
>>  Shrank that to about 250 lines of Pascal (the re-think
>>  plus leaving out the options even I never used).
>>
>>> This is what I do not like about power shell. Some of the commands
>>> are way too long to type. I like ls, df, du & co! It would be
>>> horrible to have to type list_files every time.
>>
>>  I kinda have to admit, or brag, that I never used PowerShell.
>>
>>  But yea, shortish generally IS a lot better. Longish is
>>  one reason I hate JS, and then there was COBOL  :-)
>>
>>  Haven't done a COBOL app for a long time ... I'll have
>>  to do something ... found a COBOL IDE of sorts somewhere ...
>>  ah, OpenCobolIDE (a PyPy pgm).
>>
>
> Ahh yes... forgot about javascript. It makes me cry when I see it. =(

"Rage" is MY reaction :-)

Just NO EXCUSE to make it THAT horrible.

> Note that the 250 lines of pascal could be reduced further to 1 line if
> you find out the true name of god and use that instead!

But it was writ in the Magic Crystal - and I lost it down
the commode at a Stuckeys in 1978 ........

On Wed, 27 Nov 2024 22:46:17 -0500, 186282@ud0s4.net wrote:

> In any case, best suited for web pages. That is its natural
> environment. I've writ some web stuff with kinda a lot of PHP in
> them. The most fun spawned a TEMPORARY mirror of the site in a
> TEMPORARY subdir that'd expire after 15 minutes of non-use. That way
> there was no permanent link hacks could keep attacking. The mother
> site was kept entirely off the webroot.

https://www.nusphere.com/php/php_history.htm

Like Eich, Lerdorf probably didn't expect his Personal Home Page to
spread.

On Wed, 27 Nov 2024 22:46:17 -0500, 186282@ud0s4.net wrote:

> On 11/27/24 5:13 PM, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 27 Nov 2024 01:39:34 -0500, 186282@ud0s4.net wrote:
>>
>>> On 11/25/24 4:49 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> There is a “new BASIC” that fits that description: it’s PHP.
>>>
>>> Ummmmmm ... CAN use it for general programming ... but it's not
>>> super-pleasant :-)
>>
>> It attracts the kind of people who might have used BASIC before.
>
> I never really saw it as so "BASIC-like" ...

The mentality of it.

On Wed, 27 Nov 2024 23:12:47 -0500, 186282@ud0s4.net wrote:

> But it was writ in the Magic Crystal - and I lost it down the commode
> at a Stuckeys in 1978 ........

It's a wonder I didn't lose more than pascal down the commode. They were a
southern thing when I was a kid and could look at a pecan pie without
going into insulin shock. By the time they spread I was past sugar as an
essential food group.

On 11/28/24 12:54 AM, rbowman wrote:
> On Wed, 27 Nov 2024 23:12:47 -0500, 186282@ud0s4.net wrote:
>
>> But it was writ in the Magic Crystal - and I lost it down the commode
>> at a Stuckeys in 1978 ........
>
> It's a wonder I didn't lose more than pascal down the commode. They were a
> southern thing when I was a kid and could look at a pecan pie without
> going into insulin shock. By the time they spread I was past sugar as an
> essential food group.

Yea ... I've had to go pretty heavy keto in the
past years ..... haven't eaten bread or rice or
beans or Oreo cookies in almost 10 years now.

Beats The Needle.

Really MISS the packs of Oreo cookies ....

But my dentist is happy.

Oh, are you USA ? A "Stuckeys" was a kinda low-
class crappy fast-food joint, usually located at
the exits on interstate highways. Tiny burnt
burgers. The toilets were nefarious ....... :-)

As for Pascal - it's STILL my first love. Something
'poetic' about it. Thank you Dr. Wirth ! Have
proto-ed a lot of apps in Python, only to turn
them into better FPC/Lazarus later.

STILL can't find a Modula-3 compiler for Linux
that actually works .......

On 11/28/24 12:52 AM, Lawrence D'Oliveiro wrote:
> On Wed, 27 Nov 2024 22:46:17 -0500, 186282@ud0s4.net wrote:
>
>> On 11/27/24 5:13 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Wed, 27 Nov 2024 01:39:34 -0500, 186282@ud0s4.net wrote:
>>>
>>>> On 11/25/24 4:49 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> There is a “new BASIC” that fits that description: it’s PHP.
>>>>
>>>> Ummmmmm ... CAN use it for general programming ... but it's not
>>>> super-pleasant :-)
>>>
>>> It attracts the kind of people who might have used BASIC before.
>>
>> I never really saw it as so "BASIC-like" ...
>
> The mentality of it.

Nah ... still don't see it ....

But obviously it evokes BASIC to you, so ...

On 11/28/24 12:46 AM, rbowman wrote:
> On Wed, 27 Nov 2024 22:46:17 -0500, 186282@ud0s4.net wrote:
>
>> In any case, best suited for web pages. That is its natural
>> environment. I've writ some web stuff with kinda a lot of PHP in
>> them. The most fun spawned a TEMPORARY mirror of the site in a
>> TEMPORARY subdir that'd expire after 15 minutes of non-use. That way
>> there was no permanent link hacks could keep attacking. The mother
>> site was kept entirely off the webroot.
>
> https://www.nusphere.com/php/php_history.htm
>
>
> Like Eich, Lerdorf probably didn't expect his Personal Home Page to
> spread.

Well, there IS a certain v0.5 feel about it :-)

But it still Gets It Done.

I like PHP because it makes the gigabuck SERVER do
most of the work, unlike JS.

Once wrote a short JS with lots of deep math/trig and
string stuff in it - just a few lines - to punish
people who didn't know the password. All the cooling
fans would rev up to full almost instantly :-)

Rich <rich@example.invalid> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Look I don't know how memory allocation and de allocation is done
>> but my instinct would be to hold a long list of pointers to allocated
>> blocks. Possibly in order of the allocated addresses, which would make
>> allocating a new block a case of finding the first gap in the list that
>> is [required blocksize] and inserting a new list element, and de
>> allocation a question of searching the list for a matching allocation,
>> and deleting it from the list.
>>
>> It would be trivial to get to the end of the list and discover that that
>> was the end, and, with no match found simply ignore the free call
>
> Yes, but now you burden /every/ free(ptr) call with an O(N) linear
> search of all allocated blocks to determine if "ptr" has been
> previously freed.

Obviously a real implementation would use a faster data structure. But
see my other post for why this idea isn’t enough to solve the
problem. You need either full pointer provenance tracking
(e.g. valgrind, rather slowly), or in-band pointer tagging (e.g. CHERI,
if I understand correctly) or a different allocation model which
eliminates the problem at source (e.g. any number of languages with
automated memory management).

--
https://www.greenend.org.uk/rjk/

On Thu, 28 Nov 2024 02:22:36 -0500, 186282@ud0s4.net wrote:

> Oh, are you USA ? A "Stuckeys" was a kinda low- class crappy
> fast-food joint, usually located at the exits on interstate highways.
> Tiny burnt burgers. The toilets were nefarious .......

https://en.wikipedia.org/wiki/Stuckey's

It's been over 60 years but I don't think they ever had fast food back
then. They specialized in pecans and had just the nuts, shelled or
unshelled, but had a lot of nut based candies that I would consider sickly
sweet these days. That's in keeping with southern tastes. They favor sweet
tea that a hummingbird would consider overkill.

They also had novelty gifts. I remember one was a small box labeled Pecans
that had two miniature milk cans when you opened it. The humor is obscure
unless you understand the difference between the northern and southern
pronunciations.

On the '50s and into the '60s it was a different world south of the Mason
Dixon line. When we visited my brother at Huntsville AL in '58 it was
still segregated. Wernher von Braun and his crew must have found it
ironical.

On Thu, 28 Nov 2024 02:56:51 -0500, 186282@ud0s4.net wrote:

> Well, there IS a certain v0.5 feel about it
>
> But it still Gets It Done.
>
> I like PHP because it makes the gigabuck SERVER do most of the work,
> unlike JS.
>
> Once wrote a short JS with lots of deep math/trig and string stuff in
> it - just a few lines - to punish people who didn't know the
> password. All the cooling fans would rev up to full almost instantly
>

I used CGI and FastCGI mostly, and then Node.js eventually. The server
side js did a little work but with the Esri JavaScript API the client side
did most of the heavy lifting. The backend served up GeoJSON but other
processes created it. The most work was querying the database for
historical information in a couple of applications like crime analysis.

On 27/11/2024 18:32, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 27/11/2024 01:48, Rich wrote:
>>> The only two guarantees given in that paragraph are:
>>> 1) if ptr was returned by one of the malloc's, the space referenced
>>> by
>>> ptr is deallocated (albeit only for the first call of free(ptr), per
>>> the second sentence);
>>> and
>>> 2) if ptr is NULL, nothing occurs.
>>
>> Exactly. The result of anything else is implementation dependent on
>> the library.
>>
>> One might write a free that says 'look at our list of allocated
>> blocks, compare with the pointer and if no match do nothing'
>>
>> Or one that says 'look at our list of allocated block compare with
>> the pointer and if no match, segfault'
>>
>> I am not au fait with the internal of 'free()' so I cannot comment as
>> to why the first is not always the case.
>
> You can absolutely write an allocator that does that if you want. You’ll
> pay for it in performance and memory usage, but it might well be
> worthwhile in a given application.
>
> However, it doesn’t fully solve the problem. Suppose the sequence of
> operations (with lots going on between) happens to look like this:
>
> int *p = malloc(xxx);
> // ...
> free(p);
> // ...
> int *q = malloc(yyy);
> // ...
> free(p); // double free of p
> // ...
> *q = 1;
>
> If p!=q then a tracking allocator like you envisage would spot the
> error. But if it happens that p=q (which is entirely possible) then the
> tracking allocator won’t notice the problem. The program will start to
> misbehave seriously when the it access the (now freed) memory pointed to
> be q.
>
Ah. But I cant see how to prevent that unless you give every block a UID
as well.
Which isn't a huge overhead.

> Nulling out pointers after freeing them, as suggested elsewhere helps,
> but that depends on perfect play by human programmers, not something you
> want to rely on.
>
>
> To go further you need to track not just the status of each allocation
> but the provenance of the pointers to. valgrind does that (and a lot
> more) but the performance penalty means it’s only practical to use for
> testing and debugging.
>
Yup. As above. But I still cant see how you can do the job much faster
than how I outlined above.

--
To ban Christmas, simply give turkeys the vote.

On 27/11/2024 18:58, Rich wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 27/11/2024 16:33, Rich wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 27/11/2024 01:48, Rich wrote:
>>>>> The only two guarantees given in that paragraph are:
>>>>>
>>>>> 1) if ptr was returned by one of the malloc's, the space referenced by
>>>>> ptr is deallocated (albeit only for the first call of free(ptr), per
>>>>> the second sentence);
>>>>> and
>>>>> 2) if ptr is NULL, nothing occurs.
>>>>
>>>> Exactly. The result of anything else is implementation dependent on the
>>>> library.
>>>>
>>>> One might write a free that says 'look at our list of allocated blocks,
>>>> compare with the pointer and if no match do nothing'
>>>>
>>>> Or one that says 'look at our list of allocated block compare with the
>>>> pointer and if no match, segfault'
>>>>
>>>> I am not au fait with the internal of 'free()' so I cannot comment as to
>>>> why the first is not always the case.
>>>
>>> I can hazzard a guess. The time taken to perform the search, or the
>>> effort needed to maintain an "index structure" to perform an optimized
>>> search, plus the time for the optimized search, was felt to be
>>> excessive and wasteful when the "spec" says "don't ever do this".
>>>
>>
>> Look I don't know how memory allocation and de allocation is done
>> but my instinct would be to hold a long list of pointers to allocated
>> blocks. Possibly in order of the allocated addresses, which would make
>> allocating a new block a case of finding the first gap in the list that
>> is [required blocksize] and inserting a new list element, and de
>> allocation a question of searching the list for a matching allocation,
>> and deleting it from the list.
>>
>> It would be trivial to get to the end of the list and discover that that
>> was the end, and, with no match found simply ignore the free call
>
> Yes, but now you burden /every/ free(ptr) call with an O(N) linear
> search of all allocated blocks to determine if "ptr" has been
> previously freed. With today's CPU's one could be excused in thinking
> "not such a big deal". In the days of a PDP-11 or VAX-11/780 CPU
> performance levels, doing an O(N) linear search, on every call to free,
> to catch something the programmer was never supposed to do in the first
> place, was likely viewed as too much overhead.
>
How else would you do it?

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

On 27/11/2024 19:12, rbowman wrote:
> On Wed, 27 Nov 2024 11:58:35 +0000, The Natural Philosopher wrote:
>
>> I've encountered that in my time in mil spec aerospace.
>> A very few people analysed the project and broke it down in to circuit
>> board specs.
>
> I worked on one DoD project in my career. I got bored and wandered off
> after 6 months of wrangling about the spec. About a year later I talked to
> one of the programmers who had stayed and asked if they'd written any code
> yet. "Nope."
>
> So much blood, sweat, tears, and ego involvement is involved in specs like
> that it will be implemented even if it becomes apparent it isn't going to
> work. Fiascos like the F-35 don't surprise me at all.

The amazing thing was that random monkeys did in the end through a
process of iteration 'hit upon the right thing, after exhausting every
other alternative'

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

On Wed, 27 Nov 2024, 186282@ud0s4.net wrote:

>>>
>>
>> Ahh yes... forgot about javascript. It makes me cry when I see it. =(
>
> "Rage" is MY reaction :-)
>
> Just NO EXCUSE to make it THAT horrible.

This is the truth!

>> Note that the 250 lines of pascal could be reduced further to 1 line if you
>> find out the true name of god and use that instead!
>
> But it was writ in the Magic Crystal - and I lost it down
> the commode at a Stuckeys in 1978 ........

Damn it! ;)

On Thu, 28 Nov 2024, rbowman wrote:

> On Wed, 27 Nov 2024 23:12:47 -0500, 186282@ud0s4.net wrote:
>
>> But it was writ in the Magic Crystal - and I lost it down the commode
>> at a Stuckeys in 1978 ........
>
> It's a wonder I didn't lose more than pascal down the commode. They were a
> southern thing when I was a kid and could look at a pecan pie without
> going into insulin shock. By the time they spread I was past sugar as an
> essential food group.
>

This is interesting! Have you, like me, become increasingly sensitive to
sugar as you grew older?

When I was young, I could drink enormous amounts of Coca Cola nad enjoy
it. Today it is not longer possible. At most, I can drink 15-20 cl on a
hot summer day, and that's about it.

Same with chocolate. I can eat 3-4 small pieces, and then I'm full.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 27/11/2024 18:58, Rich wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 27/11/2024 16:33, Rich wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> On 27/11/2024 01:48, Rich wrote:
>>>>>> The only two guarantees given in that paragraph are:
>>>>>>
>>>>>> 1) if ptr was returned by one of the malloc's, the space referenced by
>>>>>> ptr is deallocated (albeit only for the first call of free(ptr), per
>>>>>> the second sentence);
>>>>>> and
>>>>>> 2) if ptr is NULL, nothing occurs.
>>>>>
>>>>> Exactly. The result of anything else is implementation dependent on the
>>>>> library.
>>>>>
>>>>> One might write a free that says 'look at our list of allocated blocks,
>>>>> compare with the pointer and if no match do nothing'
>>>>>
>>>>> Or one that says 'look at our list of allocated block compare with the
>>>>> pointer and if no match, segfault'
>>>>>
>>>>> I am not au fait with the internal of 'free()' so I cannot comment as to
>>>>> why the first is not always the case.
>>>>
>>>> I can hazzard a guess. The time taken to perform the search, or the
>>>> effort needed to maintain an "index structure" to perform an optimized
>>>> search, plus the time for the optimized search, was felt to be
>>>> excessive and wasteful when the "spec" says "don't ever do this".
>>>>
>>>
>>> Look I don't know how memory allocation and de allocation is done
>>> but my instinct would be to hold a long list of pointers to allocated
>>> blocks. Possibly in order of the allocated addresses, which would make
>>> allocating a new block a case of finding the first gap in the list that
>>> is [required blocksize] and inserting a new list element, and de
>>> allocation a question of searching the list for a matching allocation,
>>> and deleting it from the list.
>>>
>>> It would be trivial to get to the end of the list and discover that that
>>> was the end, and, with no match found simply ignore the free call
>>
>> Yes, but now you burden /every/ free(ptr) call with an O(N) linear
>> search of all allocated blocks to determine if "ptr" has been
>> previously freed. With today's CPU's one could be excused in thinking
>> "not such a big deal". In the days of a PDP-11 or VAX-11/780 CPU
>> performance levels, doing an O(N) linear search, on every call to free,
>> to catch something the programmer was never supposed to do in the first
>> place, was likely viewed as too much overhead.
>>
> How else would you do it?

For performance reasons you'd want to maintain some index data
structure that can be searched faster than O(N), which becomes
additional overhead for the malloc's and for free. As well, as Richard
K. also says in his posts, just that is not enough to track and ignore
all double free operations. Which adds on even more overhead.

On 28/11/2024 14:19, Rich wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 27/11/2024 18:58, Rich wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 27/11/2024 16:33, Rich wrote:
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> On 27/11/2024 01:48, Rich wrote:
>>>>>>> The only two guarantees given in that paragraph are:
>>>>>>>
>>>>>>> 1) if ptr was returned by one of the malloc's, the space referenced by
>>>>>>> ptr is deallocated (albeit only for the first call of free(ptr), per
>>>>>>> the second sentence);
>>>>>>> and
>>>>>>> 2) if ptr is NULL, nothing occurs.
>>>>>>
>>>>>> Exactly. The result of anything else is implementation dependent on the
>>>>>> library.
>>>>>>
>>>>>> One might write a free that says 'look at our list of allocated blocks,
>>>>>> compare with the pointer and if no match do nothing'
>>>>>>
>>>>>> Or one that says 'look at our list of allocated block compare with the
>>>>>> pointer and if no match, segfault'
>>>>>>
>>>>>> I am not au fait with the internal of 'free()' so I cannot comment as to
>>>>>> why the first is not always the case.
>>>>>
>>>>> I can hazzard a guess. The time taken to perform the search, or the
>>>>> effort needed to maintain an "index structure" to perform an optimized
>>>>> search, plus the time for the optimized search, was felt to be
>>>>> excessive and wasteful when the "spec" says "don't ever do this".
>>>>>
>>>>
>>>> Look I don't know how memory allocation and de allocation is done
>>>> but my instinct would be to hold a long list of pointers to allocated
>>>> blocks. Possibly in order of the allocated addresses, which would make
>>>> allocating a new block a case of finding the first gap in the list that
>>>> is [required blocksize] and inserting a new list element, and de
>>>> allocation a question of searching the list for a matching allocation,
>>>> and deleting it from the list.
>>>>
>>>> It would be trivial to get to the end of the list and discover that that
>>>> was the end, and, with no match found simply ignore the free call
>>>
>>> Yes, but now you burden /every/ free(ptr) call with an O(N) linear
>>> search of all allocated blocks to determine if "ptr" has been
>>> previously freed. With today's CPU's one could be excused in thinking
>>> "not such a big deal". In the days of a PDP-11 or VAX-11/780 CPU
>>> performance levels, doing an O(N) linear search, on every call to free,
>>> to catch something the programmer was never supposed to do in the first
>>> place, was likely viewed as too much overhead.
>>>
>> How else would you do it?
>
> For performance reasons you'd want to maintain some index data
> structure that can be searched faster than O(N), which becomes
> additional overhead for the malloc's and for free. As well, as Richard
> K. also says in his posts, just that is not enough to track and ignore
> all double free operations. Which adds on even more overhead.
>
Its not hard to do a binary search on an ordered linked list, and its a
piece if piss to insert to make it ordered

--
“it should be clear by now to everyone that activist environmentalism
(or environmental activism) is becoming a general ideology about humans,
about their freedom, about the relationship between the individual and
the state, and about the manipulation of people under the guise of a
'noble' idea. It is not an honest pursuit of 'sustainable development,'
a matter of elementary environmental protection, or a search for
rational mechanisms designed to achieve a healthy environment. Yet
things do occur that make you shake your head and remind yourself that
you live neither in Joseph Stalin’s Communist era, nor in the Orwellian
utopia of 1984.”

Vaclav Klaus

On 28/11/2024 10:04, D wrote:
>
>
> On Thu, 28 Nov 2024, rbowman wrote:
>
>> On Wed, 27 Nov 2024 23:12:47 -0500, 186282@ud0s4.net wrote:
>>
>>>    But it was writ in the Magic Crystal - and I lost it down the commode
>>>    at a Stuckeys in 1978 ........
>>
>> It's a wonder I didn't lose more than pascal down the commode. They
>> were a
>> southern thing when I was a kid and could look at a pecan pie without
>> going into insulin shock. By the time they spread I was past sugar as an
>> essential food group.
>>
>
> This is interesting! Have you, like me, become increasingly sensitive to
> sugar as you grew older?
>
> When I was young, I could drink enormous amounts of Coca Cola nad enjoy
> it. Today it is not longer possible. At most, I can drink 15-20 cl on a
> hot summer day, and that's about it.
>
> Same with chocolate. I can eat 3-4 small pieces, and then I'm full.

Sadly with age I have had to abandon nearly all starch, as well as
nearly all vegetables. I have more than one condition kept in check my
diets so strict they make life increasingly miserable...it's now more a
question of what I can eat, rather than what I can't.

Life's a bitch
And then you die.

--
Future generations will wonder in bemused amazement that the early
twenty-first century’s developed world went into hysterical panic over a
globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to
contemplate a rollback of the industrial age.

Richard Lindzen

On 2024-11-27, D <nospam@example.net> wrote:

> On Wed, 27 Nov 2024, rbowman wrote:
>
>> On Wed, 27 Nov 2024 10:12:06 +0100, D wrote:
>>
>>> Ahh yes... forgot about javascript. It makes me cry when I see it. =(
>>
>> Apropos:
>>
>> https://www.infoworld.com/article/3612364/uspto-petitioned-to-cancel-
>> oracles-javascript-trademark.html
>>
>> Oracle is doing their usual dog in the manger tactic with ECMAScript.
>> They acquired the trademark from Sun and never had a part in it. I wonder
>> if Eich wakes up at 3 AM thinking about what he created? He wasn't happy
>> with the name in the first place.
>
> Ahh Oracle... a perfect example of what the maffia would look like if they
> were a corporation. ;)

I saw a wonderful tongue-in-cheek article years ago (and unfortunately can't
find it again). ("Your CPU will melt! And you'll PAY us for the privilege!")
It ended with the words:

We have a hammer.
Your problem is a nail.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On Thu, 28 Nov 2024, The Natural Philosopher wrote:

> On 28/11/2024 10:04, D wrote:
>>
>>
>> On Thu, 28 Nov 2024, rbowman wrote:
>>
>>> On Wed, 27 Nov 2024 23:12:47 -0500, 186282@ud0s4.net wrote:
>>>
>>>>    But it was writ in the Magic Crystal - and I lost it down the commode
>>>>    at a Stuckeys in 1978 ........
>>>
>>> It's a wonder I didn't lose more than pascal down the commode. They were a
>>> southern thing when I was a kid and could look at a pecan pie without
>>> going into insulin shock. By the time they spread I was past sugar as an
>>> essential food group.
>>>
>>
>> This is interesting! Have you, like me, become increasingly sensitive to
>> sugar as you grew older?
>>
>> When I was young, I could drink enormous amounts of Coca Cola nad enjoy it.
>> Today it is not longer possible. At most, I can drink 15-20 cl on a hot
>> summer day, and that's about it.
>>
>> Same with chocolate. I can eat 3-4 small pieces, and then I'm full.
>
> Sadly with age I have had to abandon nearly all starch, as well as nearly all
> vegetables. I have more than one condition kept in check my diets so strict
> they make life increasingly miserable...it's now more a question of what I
> can eat, rather than what I can't.

This is very sad to hear. Maybe someone wise in the ways of science can
come up with a better cure than just diet restrictions?

> Life's a bitch
> And then you die.

Ahh! But then you go to heaven and get free music lessons!

On Thu, 28 Nov 2024, Charlie Gibbs wrote:

> On 2024-11-27, D <nospam@example.net> wrote:
>
>> On Wed, 27 Nov 2024, rbowman wrote:
>>
>>> On Wed, 27 Nov 2024 10:12:06 +0100, D wrote:
>>>
>>>> Ahh yes... forgot about javascript. It makes me cry when I see it. =(
>>>
>>> Apropos:
>>>
>>> https://www.infoworld.com/article/3612364/uspto-petitioned-to-cancel-
>>> oracles-javascript-trademark.html
>>>
>>> Oracle is doing their usual dog in the manger tactic with ECMAScript.
>>> They acquired the trademark from Sun and never had a part in it. I wonder
>>> if Eich wakes up at 3 AM thinking about what he created? He wasn't happy
>>> with the name in the first place.
>>
>> Ahh Oracle... a perfect example of what the maffia would look like if they
>> were a corporation. ;)
>
> I saw a wonderful tongue-in-cheek article years ago (and unfortunately can't
> find it again). ("Your CPU will melt! And you'll PAY us for the privilege!")
> It ended with the words:
>
> We have a hammer.
> Your problem is a nail.

Brilliant!