On Sun, 3 Mar 2024 21:23:56 +0100, David Brown wrote:

> But consider this. When programming in modern C++, you can be risk-free
> from buffer overruns and most kinds of memory leak - use container
> classes, string classes, and the like, rather than C-style arrays and
> malloc/free or new/delete.

Or, going further, how about Google‘s “Carbon” project
<https://github.com/carbon-language/carbon-lang>, which tries to keep
the good bits from C++ while chucking out the bad?

On 3/3/2024 3:29 PM, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 14:06:31 -0800, Chris M. Thomasson wrote:
>
>> On 3/3/2024 12:10 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>>>
>>>> It is not languages like C and C++ that are "unsafe".
>>>
>>> Some empirical evidence from Google
>>> <https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
>>> shows a reduction in memory-safety errors in switching from C/C++ to
>>> Rust.
>>
>> Sure. Putting corks on the forks reduces the chance of eye injuries.
>
> Except this is Google, and they’re doing it in real-world production
> code, namely Android. And showing some positive benefits from doing
> so, without impairing the functionality of Android in any way.
>
> Not like “putting corks on the forks”, whatever that might be about
> ...

Putting corks on the forks is necessary to prevent the programmer from
hurting itself or others... ;^)

Lynn McGuire <lynnmcguire5@gmail.com> wrote in
news:us0brl$246bf$1@dont-email.me:

> "White House to Developers: Using C or C++ Invites Cybersecurity
> Risks"
>
> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
> invites-cybersecurity-risks
>
> "The Biden administration backs a switch to more memory-safe
> programming languages. The tech industry sees their point, but it
> won't be easy."
>
> No. The feddies want to regulate software development very much.
> They have been talking about it for at least 20 years now. This is a
> very bad thing.
>
> Lynn

I was thinking about this wrt other alledgedly more secure languages. They
can be hacked just as easily as C and C++ and many other languages. The
government should worry about things they really need to control, which is
less not more, IMHO. They obviously know very little about computer
development.

David
Professional developer for nearly 45 years

On 3/3/2024 3:59 PM, David LaRue wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
> news:us0brl$246bf$1@dont-email.me:
>
>> "White House to Developers: Using C or C++ Invites Cybersecurity
>> Risks"
>>
>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
>> invites-cybersecurity-risks
>>
>> "The Biden administration backs a switch to more memory-safe
>> programming languages. The tech industry sees their point, but it
>> won't be easy."
>>
>> No. The feddies want to regulate software development very much.
>> They have been talking about it for at least 20 years now. This is a
>> very bad thing.
>>
>> Lynn
>
> I was thinking about this wrt other alledgedly more secure languages. They
> can be hacked just as easily as C and C++ and many other languages. The
> government should worry about things they really need to control, which is
> less not more, IMHO. They obviously know very little about computer
> development.
[...]

I remember a while back when some people would try to tell me that ADA
solves all issues...

In article <us2s96$2n6h3$6@dont-email.me>,
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
....
>Sure. Putting corks on the forks reduces the chance of eye injuries.
>Fwiw, a YouTube link to a scene in the movie Dirty Rotten Scoundrels:
>Funny to me:
>
>
>https://youtu.be/eF8QAeQm3ZM?t=332

Leader Keith gets mad when you post YouTube URLs here.

I'd be more careful, if I were you.

>Putting the cork on the fork is akin to saying nobody should be using C
>and/or C++ in this "modern" age? :^)
--
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/ModernXtian

On 03/03/2024 23:29, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 14:06:31 -0800, Chris M. Thomasson wrote:
>
>> On 3/3/2024 12:10 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>>>
>>>> It is not languages like C and C++ that are "unsafe".
>>>
>>> Some empirical evidence from Google
>>> <https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
>>> shows a reduction in memory-safety errors in switching from C/C++ to
>>> Rust.
>>
>> Sure. Putting corks on the forks reduces the chance of eye injuries.
>
> Except this is Google, and they’re doing it in real-world production
> code, namely Android. And showing some positive benefits from doing
> so, without impairing the functionality of Android in any way.

That's great. So long as it is somebody else is programming in one of
those languages where you have one hand tied behind your back. That used
to be Ada. Now apparently it is Rust (so more like both hands tied).

In the piechart in your link however, new code in C/C++ still looks to
be nearly 3 times as much as Rust.

Personally I think there must be an easier language which is considered
to be safer without also making coding a nightmare.

On Sun, 3 Mar 2024 16:06:24 -0800, Chris M. Thomasson wrote:

> I remember a while back when some people would try to tell me that [Ada]
> solves all issues...

It did make a difference. Did you know the life-support system on the
International Space Station was written in Ada? Not something you
would trust C++ code to, let’s face it.

And here
<https://devclass.com/2022/11/08/spark-as-good-as-rust-for-safer-coding-adacore-cites-nvidia-case-study/>
is a project to make it even safer.

On 03/03/2024 23:01, Chris M. Thomasson wrote:
> On 3/3/2024 12:23 PM, David Brown wrote:
>> On 03/03/2024 19:18, Kaz Kylheku wrote:

>>> Embedded systems often need custom memory management, not something that
>>> the language imposes. C has malloc, yet even that gets disused in favor
>>> of something else.
>>>
>>
>> For safe embedded systems, you don't want memory management at all.
>> Avoiding dynamic memory is an important aspect of safety-critical
>> embedded development.
>>
>
> You still have to think about memory management even if you avoid any
> dynamic memory? How are you going to mange this memory wrt your various
> data structures needs....

To be clear here - sometimes you can't avoid all use of dynamic memory
and therefore memory management. And as Kaz says, you will often use
custom solutions such as resource pools rather than generic malloc/free.
Flexible network communication (such as Ethernet or other IP
networking) is hard to do without dynamic memory.

But for things that are safety or reliability critical, you aim to have
everything statically allocated. (Sometimes you use dynamic memory at
startup for convenience, but you never free that memory.) This, of
course, means you simply don't use certain kinds of data structures.
std::array<> is fine - it's just a nicer type wrapper around a fixed
size C-style array. But you don't use std::vector<>, or other growable
structures. You figure out in advance the maximum size you need for
your structures, and nail them to that size at compile time.

There are three big run-time dangers and one big build-time limitation
when you have dynamic memory:

1. You can run out. PC's can often be assumed to have "limitless"
memory, and it is also often fine for a PC program to say it can't load
that big file until you close other programs and free up memory. In a
safety-critical embedded system, you have limited ram, and your code
never does things it does not have to do - consequently, it is not
acceptable to say it can't run a task at the moment due to lack of memory.

2. You get fragmentation from malloc/free, leading to allocation
failures even when there is enough total free memory. Small embedded
systems don't have virtual memory, paging, MMUs, and other ways to
re-arrange the appearance of memory. If you free your memory in a
different order from allocation, your heap gets fragmented, and you end
up with your "free" memory consisting of lots of discontinuous bits.

3. Your timing is hard to predict or constrain. Walking heaps to find
free memory for malloc, or coalescing free segments on deallocation,
often has very unpredictable timing. This is a big no-no for real time
systems.

And at design/build time, dynamic memory requires are extremely
difficult to analyse. In comparison, if everything is allocated
statically, it's simple - it's all there in your map files, and you have
a pass/fail result from trying to link it all within the available
memory of the target.

On 04/03/2024 08:44, David Brown wrote:
> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>> On 3/3/2024 12:23 PM, David Brown wrote:
>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>
>>>> Embedded systems often need custom memory management, not something
>>>> that
>>>> the language imposes. C has malloc, yet even that gets disused in favor
>>>> of something else.
>>>>
>>>
>>> For safe embedded systems, you don't want memory management at all.
>>> Avoiding dynamic memory is an important aspect of safety-critical
>>> embedded development.
>>>
>>
>> You still have to think about memory management even if you avoid any
>> dynamic memory? How are you going to mange this memory wrt your
>> various data structures needs....
>
> To be clear here - sometimes you can't avoid all use of dynamic memory
> and therefore memory management.  And as Kaz says, you will often use
> custom solutions such as resource pools rather than generic malloc/free.
>  Flexible network communication (such as Ethernet or other IP
> networking) is hard to do without dynamic memory.
>
> But for things that are safety or reliability critical, you aim to have
> everything statically allocated.  (Sometimes you use dynamic memory at
> startup for convenience, but you never free that memory.)  This, of
> course, means you simply don't use certain kinds of data structures.
> std::array<> is fine - it's just a nicer type wrapper around a fixed
> size C-style array.  But you don't use std::vector<>, or other growable
> structures.  You figure out in advance the maximum size you need for
> your structures, and nail them to that size at compile time.
>
And if it's embedded, it's unlikely to have an unbounded dataset thrown
at it, because embedded systems aren't used for those types of problems.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/03/2024 23:29, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 14:06:31 -0800, Chris M. Thomasson wrote:
>
>> On 3/3/2024 12:10 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 3 Mar 2024 12:01:57 +0100, David Brown wrote:
>>>
>>>> It is not languages like C and C++ that are "unsafe".
>>>
>>> Some empirical evidence from Google
>>> <https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>
>>> shows a reduction in memory-safety errors in switching from C/C++ to
>>> Rust.
>>
>> Sure. Putting corks on the forks reduces the chance of eye injuries.
>
> Except this is Google, and they’re doing it in real-world production
> code, namely Android. And showing some positive benefits from doing
> so, without impairing the functionality of Android in any way.
>
> Not like “putting corks on the forks”, whatever that might be about
> ...

And it's pump money at it until something which is not going to a goer
for anyone else starts to be a goer, and it is now made to work. And of
course Google can solve a problem by inventing a new language and
putting up all the infrastructure that that would need around it.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 04/03/2024 00:06, Chris M. Thomasson wrote:
> On 3/3/2024 3:59 PM, David LaRue wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>> news:us0brl$246bf$1@dont-email.me:
>>
>>> "White House to Developers: Using C or C++ Invites Cybersecurity
>>> Risks"
>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
>>> invites-cybersecurity-risks
>>>
>>> "The Biden administration backs a switch to more memory-safe
>>> programming languages. The tech industry sees their point, but it
>>> won't be easy."
>>>
>>> No.  The feddies want to regulate software development very much.
>>> They have been talking about it for at least 20 years now.  This is a
>>> very bad thing.
>>>
>>> Lynn
>>
>> I was thinking about this wrt other alledgedly more secure languages.
>> They
>> can be hacked just as easily as C and C++ and many other languages.  The
>> government should worry about things they really need to control,
>> which is
>> less not more, IMHO.  They obviously know very little about computer
>> development.
> [...]
>
> I remember a while back when some people would try to tell me that ADA
> solves all issues...
>
And there's ADA, and there's Ada, the lady.

And she wrote.

"The Analytical Engine has no pretensions whatever to originate
anything. It can do whatever we know how to order it to perform. It can
follow analysis; but it has no power of anticipating any analytical
relations or truths."

And so she knew what the capabilites of the Analytical Engine were,
exactly what programming was, what and what it could not achieve, and
how set out making it achieve what it could achieved. And so she had it,
and in a sense, ADA solved all issues.

And no formal computer science education. Of course.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

All,

> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>
> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>
> "The Biden administration backs a switch to more memory-safe programming languages. The tech industry sees their point,
> but it won't be easy."

They make the mistake of blaming the tools rather than
how the tools are used
https://shape-of-code.com/2024/03/03/the-whitehouse-report-on-adopting-memory-safety/

On 04/03/2024 12:54, Malcolm McLean wrote:
> On 04/03/2024 00:06, Chris M. Thomasson wrote:
>> On 3/3/2024 3:59 PM, David LaRue wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>> news:us0brl$246bf$1@dont-email.me:
>>>
>>>> "White House to Developers: Using C or C++ Invites Cybersecurity
>>>> Risks"
>>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
>>>> invites-cybersecurity-risks
>>>>
>>>> "The Biden administration backs a switch to more memory-safe
>>>> programming languages. The tech industry sees their point, but it
>>>> won't be easy."
>>>>
>>>> No.  The feddies want to regulate software development very much.
>>>> They have been talking about it for at least 20 years now.  This is a
>>>> very bad thing.
>>>>
>>>> Lynn
>>>
>>> I was thinking about this wrt other alledgedly more secure languages.
>>> They
>>> can be hacked just as easily as C and C++ and many other languages.  The
>>> government should worry about things they really need to control,
>>> which is
>>> less not more, IMHO.  They obviously know very little about computer
>>> development.
>> [...]
>>
>> I remember a while back when some people would try to tell me that ADA
>> solves all issues...
>>
> And there's ADA, and there's Ada, the lady.

No, there's Ada the programming language, named after Lady Ada Lovelace.

For those that perhaps don't understand these things, all-caps names are
usually used for acronyms, such as BASIC, or languages from before small
letters were universal in computer systems, such as early FORTRAN.
Programming languages named after people are generally capitalised the
same way people's names are - thus Ada and Pascal.

>
> And she wrote.
>
> "The Analytical Engine has no pretensions whatever to originate
> anything. It can do whatever we know how to order it to perform. It can
> follow analysis; but it has no power of anticipating any analytical
> relations or truths."
>
> And so she knew what the capabilites of the Analytical Engine were,
> exactly what programming was, what and what it could not achieve, and
> how set out making it achieve what it could achieved. And so she had it,
> and in a sense, ADA solved all issues.
>

What I think you are trying to say, but got completely lost in the last
sentence, is that Lady Ada Lovelace is often regarded (perhaps
incorrectly) as the first computer programmer.

> And no formal computer science education. Of course.

She had a great deal of education in mathematics - just like most
computer science pioneers.

David Brown <david.brown@hesbynett.no> writes:
>On 04/03/2024 12:54, Malcolm McLean wrote:
>> On 04/03/2024 00:06, Chris M. Thomasson wrote:
>>> On 3/3/2024 3:59 PM, David LaRue wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>>> news:us0brl$246bf$1@dont-email.me:
>>>>
>>>>> "White House to Developers: Using C or C++ Invites Cybersecurity
>>>>> Risks"
>>>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
>>>>> invites-cybersecurity-risks
>>>>>
>>>>> "The Biden administration backs a switch to more memory-safe
>>>>> programming languages. The tech industry sees their point, but it
>>>>> won't be easy."
>>>>>
>>>>> No.  The feddies want to regulate software development very much.
>>>>> They have been talking about it for at least 20 years now.  This is a
>>>>> very bad thing.
>>>>>
>>>>> Lynn
>>>>
>>>> I was thinking about this wrt other alledgedly more secure languages.
>>>> They
>>>> can be hacked just as easily as C and C++ and many other languages.  The
>>>> government should worry about things they really need to control,
>>>> which is
>>>> less not more, IMHO.  They obviously know very little about computer
>>>> development.
>>> [...]
>>>
>>> I remember a while back when some people would try to tell me that ADA
>>> solves all issues...
>>>
>> And there's ADA, and there's Ada, the lady.
>
>No, there's Ada the programming language, named after Lady Ada Lovelace.\

Indeed. And ADA has a very different meaning stateside.

On 03.03.2024 21:23, David Brown wrote:
>
> [...] Shortcuts are taken because
> the sales people need the code by tomorrow morning, and there are only
> so many hours in the night to get it working.

An indication of bad project management (or none at all) to control
development according to a realistic plan.

Janis

On 04/03/2024 17:05, Janis Papanagnou wrote:
> On 03.03.2024 21:23, David Brown wrote:
>>
>> [...] Shortcuts are taken because
>> the sales people need the code by tomorrow morning, and there are only
>> so many hours in the night to get it working.
>
> An indication of bad project management (or none at all) to control
> development according to a realistic plan.
>

Now you are beginning to understand!

On 04/03/2024 14:41, David Brown wrote:
> On 04/03/2024 12:54, Malcolm McLean wrote:
>> On 04/03/2024 00:06, Chris M. Thomasson wrote:
>>> On 3/3/2024 3:59 PM, David LaRue wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>>> news:us0brl$246bf$1@dont-email.me:
>>>>
>>>>> "White House to Developers: Using C or C++ Invites Cybersecurity
>>>>> Risks"
>>>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-
>>>>> invites-cybersecurity-risks
>>>>>
>>>>> "The Biden administration backs a switch to more memory-safe
>>>>> programming languages. The tech industry sees their point, but it
>>>>> won't be easy."
>>>>>
>>>>> No.  The feddies want to regulate software development very much.
>>>>> They have been talking about it for at least 20 years now.  This is a
>>>>> very bad thing.
>>>>>
>>>>> Lynn
>>>>
>>>> I was thinking about this wrt other alledgedly more secure
>>>> languages. They
>>>> can be hacked just as easily as C and C++ and many other languages.
>>>> The
>>>> government should worry about things they really need to control,
>>>> which is
>>>> less not more, IMHO.  They obviously know very little about computer
>>>> development.
>>> [...]
>>>
>>> I remember a while back when some people would try to tell me that
>>> ADA solves all issues...
>>>
>> And there's ADA, and there's Ada, the lady.
>
> No, there's Ada the programming language, named after Lady Ada Lovelace.
>
> For those that perhaps don't understand these things, all-caps names are
> usually used for acronyms, such as BASIC, or languages from before small
> letters were universal in computer systems, such as early FORTRAN.
> Programming languages named after people are generally capitalised the
> same way people's names are - thus Ada and Pascal.
>
>>
>> And she wrote.
>>
>> "The Analytical Engine has no pretensions whatever to originate
>> anything. It can do whatever we know how to order it to perform. It
>> can follow analysis; but it has no power of anticipating any
>> analytical relations or truths."
>>
>> And so she knew what the capabilites of the Analytical Engine were,
>> exactly what programming was, what and what it could not achieve, and
>> how set out making it achieve what it could achieved. And so she had
>> it, and in a sense, ADA solved all issues.
>>
>
> What I think you are trying to say, but got completely lost in the last
> sentence, is that Lady Ada Lovelace is often regarded (perhaps
> incorrectly) as the first computer programmer.
>
So what I'm trying to say is that she did it, and everyone else just
knocked out the code. Once you understand what you are doing in this
way, it's wrapped up. She solved it. So early on.

Look at sentence two. She knew what that machine was.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 3/4/2024 12:44 AM, David Brown wrote:
> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>> On 3/3/2024 12:23 PM, David Brown wrote:
>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>
>>>> Embedded systems often need custom memory management, not something
>>>> that
>>>> the language imposes. C has malloc, yet even that gets disused in favor
>>>> of something else.
>>>>
>>>
>>> For safe embedded systems, you don't want memory management at all.
>>> Avoiding dynamic memory is an important aspect of safety-critical
>>> embedded development.
>>>
>>
>> You still have to think about memory management even if you avoid any
>> dynamic memory? How are you going to mange this memory wrt your
>> various data structures needs....
>
> To be clear here - sometimes you can't avoid all use of dynamic memory
> and therefore memory management.  And as Kaz says, you will often use
> custom solutions such as resource pools rather than generic malloc/free.
>  Flexible network communication (such as Ethernet or other IP
> networking) is hard to do without dynamic memory.
[...]

Think of using a big chunk of memory, never needed to be freed and is
just there per process. Now, you carve it up and store it in a cache
that has functions push and pop. So, you still have to manage memory
even when you are using no dynamic memory at all... Fair enough, in a
sense? The push and the pop are your malloc and free in a strange sense...

On 3/4/2024 12:36 PM, Chris M. Thomasson wrote:
> On 3/4/2024 12:44 AM, David Brown wrote:
>> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>>> On 3/3/2024 12:23 PM, David Brown wrote:
>>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>>
>>>>> Embedded systems often need custom memory management, not something
>>>>> that
>>>>> the language imposes. C has malloc, yet even that gets disused in
>>>>> favor
>>>>> of something else.
>>>>>
>>>>
>>>> For safe embedded systems, you don't want memory management at all.
>>>> Avoiding dynamic memory is an important aspect of safety-critical
>>>> embedded development.
>>>>
>>>
>>> You still have to think about memory management even if you avoid any
>>> dynamic memory? How are you going to mange this memory wrt your
>>> various data structures needs....
>>
>> To be clear here - sometimes you can't avoid all use of dynamic memory
>> and therefore memory management.  And as Kaz says, you will often use
>> custom solutions such as resource pools rather than generic
>> malloc/free.   Flexible network communication (such as Ethernet or
>> other IP networking) is hard to do without dynamic memory.
> [...]
>
> Think of using a big chunk of memory,

Say your program gains a special pointer from the system that contains
all of the memory it can use for its lifetime. Its there, and there is
no way to allocate any more...

> never needed to be freed and is
> just there per process. Now, you carve it up and store it in a cache
> that has functions push and pop. So, you still have to manage memory
> even when you are using no dynamic memory at all... Fair enough, in a
> sense? The push and the pop are your malloc and free in a strange sense...
>

On 3/4/2024 3:38 AM, Malcolm McLean wrote:
> On 04/03/2024 08:44, David Brown wrote:
>> On 03/03/2024 23:01, Chris M. Thomasson wrote:
>>> On 3/3/2024 12:23 PM, David Brown wrote:
>>>> On 03/03/2024 19:18, Kaz Kylheku wrote:
>>
>>>>> Embedded systems often need custom memory management, not something
>>>>> that
>>>>> the language imposes. C has malloc, yet even that gets disused in
>>>>> favor
>>>>> of something else.
>>>>>
>>>>
>>>> For safe embedded systems, you don't want memory management at all.
>>>> Avoiding dynamic memory is an important aspect of safety-critical
>>>> embedded development.
>>>>
>>>
>>> You still have to think about memory management even if you avoid any
>>> dynamic memory? How are you going to mange this memory wrt your
>>> various data structures needs....
>>
>> To be clear here - sometimes you can't avoid all use of dynamic memory
>> and therefore memory management.  And as Kaz says, you will often use
>> custom solutions such as resource pools rather than generic
>> malloc/free.   Flexible network communication (such as Ethernet or
>> other IP networking) is hard to do without dynamic memory.
>>
>> But for things that are safety or reliability critical, you aim to
>> have everything statically allocated.  (Sometimes you use dynamic
>> memory at startup for convenience, but you never free that memory.)
>> This, of course, means you simply don't use certain kinds of data
>> structures. std::array<> is fine - it's just a nicer type wrapper
>> around a fixed size C-style array.  But you don't use std::vector<>,
>> or other growable structures.  You figure out in advance the maximum
>> size you need for your structures, and nail them to that size at
>> compile time.
> >
> And if it's embedded, it's unlikely to have an unbounded dataset thrown
> at it, because embedded systems aren't used for those types of problems.
>

Fwiw, this older experimental allocator (2009) works on restricted
memory systems. Please forgive the alignment hacks... ;^)

https://pastebin.com/raw/f37a23918
(to raw text, no ads wrt pastebin)

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

On 3/4/2024 4:18 AM, Derek wrote:
> All,
>
>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks"
>>
>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks
>>
>> "The Biden administration backs a switch to more memory-safe
>> programming languages. The tech industry sees their point, but it
>> won't be easy."
>
> They make the mistake of blaming the tools rather than
> how the tools are used
> https://shape-of-code.com/2024/03/03/the-whitehouse-report-on-adopting-memory-safety/
>

Akin to giving somebody a hammer and they proceed to smash their own
hand with it. Then they say, well, that hammer is dangerous and the
person that gave it to me should be sued for negligence... Wow, lets
think about writing up a 1000 pages on why hammers should be banned?
Hyper sarcastic, I know, but it the key fits... ;^)

Sorry for the sarcasm.

On 3/3/2024 4:44 PM, Kenny McCormack wrote:
> In article <us2s96$2n6h3$6@dont-email.me>,
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> ...
>> Sure. Putting corks on the forks reduces the chance of eye injuries.
>> Fwiw, a YouTube link to a scene in the movie Dirty Rotten Scoundrels:
>> Funny to me:
>>
>>
>> https://youtu.be/eF8QAeQm3ZM?t=332
>
> Leader Keith gets mad when you post YouTube URLs here.
>
> I'd be more careful, if I were you.

Well, at least I added in a description... ;^)

>
>> Putting the cork on the fork is akin to saying nobody should be using C
>> and/or C++ in this "modern" age? :^)

On Mon, 4 Mar 2024 11:44:06 +0000, Malcolm McLean wrote:

> And of course Google can solve a problem by inventing a new language and
> putting up all the infrastructure that that would need around it.

Google has invented quite a lot of languages: Dart and Go come to mind,
and also this “Carbon” effort.

I suppose nowadays a language can find a niche outside the mainstream, and
still be viable. Proprietary products need mass-market success to stay
afloat, but with open-source ones, what’s important is the contributor
base, not the user base.

On Mon, 4 Mar 2024 15:41:43 +0100, David Brown wrote:

> ... Lady Ada Lovelace is often regarded (perhaps
> incorrectly) as the first computer programmer.

She was the first, in written records, to appreciate some of the not-so-
obvious issues in computer programming.

On 3/3/2024 9:43 PM, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 16:06:24 -0800, Chris M. Thomasson wrote:
>
>> I remember a while back when some people would try to tell me that [Ada]
>> solves all issues...
>
> It did make a difference. Did you know the life-support system on the
> International Space Station was written in Ada? Not something you
> would trust C++ code to, let’s face it.

Would you trust a "safe" language that had some critical libraries that
were written in say, C?

>
> And here
> <https://devclass.com/2022/11/08/spark-as-good-as-rust-for-safer-coding-adacore-cites-nvidia-case-study/>
> is a project to make it even safer.