The feddies want to regulate software development very much.
They have been talking about it for at least 20 years now.
"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.
It is not languages like C and C++ that are "unsafe".
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.
... Lady Ada Lovelace is often regarded (perhaps
incorrectly) as the first computer programmer.
Would you trust a "safe" language that had some critical libraries that
were written in say, C?
... I actually have had a Professional Engineer's License in Texas for
34 years now and can tell you all about what it takes to get one and
what it takes to keep one.
On Tue, 5 Mar 2024 00:03:54 -0600, Lynn McGuire wrote:
On 3/3/2024 11:43 PM, Lawrence D'Oliveiro wrote:
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.
Most of the Ada code was written in C or C++ and converted to Ada for
delivery.
Was it debugged again? Or was it assumed that the translation was bug-
free?
On 3/5/2024 1:01 AM, David Brown wrote:
On 04/03/2024 21:36, 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, 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...
I believe I mentioned that. You do not, in general, "push and pop" -
you malloc and never free. Excluding debugging code and other parts
useful in testing and developing, you have something like :
enum { heap_size = 16384; }
alignas(max_align_t) static uint8_t heap[heap_size];
uint8_t * next_free = heap;
void free(void * ptr) {
(void) ptr;
}
void * malloc(size_t size) {
const size_t align = alignof(max_align_t);
const real_size = size ? (size + (align - 1)) & ~(align - 1)
: align;
void * p = next_free;
next_free += real_size;
return p;
}
Allowing for pops requires storing the size of the allocations (unless
you change the API from that of malloc/free), and is only rarely
useful. Generally if you want memory that temporary, you use a VLA
or alloca to put it on the stack.
wrt systems with no malloc/free I am thinking more along the lines of a region allocator mixed with a LIFO for a cache, so a node based thing.
The region allocator gets fed with a large buffer. Depending on specific needs, it can work out nicely for systems that do not have malloc/free.
The pattern I used iirc, was something like:
// pseudo code...
_______________________
node*
node_pop()
{
// try the lifo first...
node* n = lifo_pop();
if (! n)
{
// resort to the region allocator...
n = region_allocate_node();
// note, n can be null here.
// if it is, we are out of memory.
// note, out of memory on a system
// with no malloc/free...
}
return n;
}
void
node_push(
node* n
) {
lifo_push(n);
}
_______________________
make any sense to you?
On 06/03/2024 13:31, David Brown wrote:
On 05/03/2024 23:34, Chris M. Thomasson wrote:
On 3/5/2024 2:11 PM, Keith Thompson wrote:
"Chris M. Thomasson" <[email protected]> writes:
[...]
ADA is bullet proof... Until its not... ;^)
The language is called Ada, not ADA.
I wonder how many people got confused?
Apparently you and Malcolm got confused.
Others who mentioned the language know it is called "Ada".� I not
only corrected you, but gave an explanation of it, in the hope that
with that clarity, you'd learn.
Whoever wrote this short Wikipedia article on it got confused too as
it uses both Ada and ADA:
https://simple.wikipedia.org/wiki/Ada_(programming_language)
(The example program also includes 'Ada' as some package name. Since
it is case-insensitive, 'ADA' would also work.)
Here's also a paper that uses 'ADA' (I assume it is the same
language):
https://www.sciencedirect.com/science/article/abs/pii/0166361582900136
Personally I'm not bothered whether anyone uses Ada or ADA. Is 'C'
written in all-caps or only capitalised? You can't tell!
On Wed, 6 Mar 2024 13:50:16 +0000
bart <[email protected]> wrote:
Whoever wrote this short Wikipedia article on it got confused too as
it uses both Ada and ADA:
https://simple.wikipedia.org/wiki/Ada_(programming_language)
(The example program also includes 'Ada' as some package name. Since
it is case-insensitive, 'ADA' would also work.)
Your link is to "simple Wikipedia". I don't know what it is
exactly, but it does not appear as authoritative as real Wikipedia
https://en.wikipedia.org/wiki/Ada_(programming_language)
Here's also a paper that uses 'ADA' (I assume it is the same
language):
https://www.sciencedirect.com/science/article/abs/pii/0166361582900136
The article published 1982. The language became official in 1983.
Possibly, in 1982 there still was a confusion w.r.t. its name.
Personally I'm not bothered whether anyone uses Ada or ADA. Is 'C'
written in all-caps or only capitalised? You can't tell!
If only ADA, written in upper case, was not widely used for something
else...
On Wed, 6 Mar 2024 13:50:16 +0000...
bart <[email protected]> wrote:
Whoever wrote this short Wikipedia article on it got confused too as
it uses both Ada and ADA:
https://simple.wikipedia.org/wiki/Ada_(programming_language)
(The example program also includes 'Ada' as some package name. Since
it is case-insensitive, 'ADA' would also work.)
Your link is to "simple Wikipedia". I don't know what it is
exactly, but it does not appear as authoritative as real Wikipedia
On 3/6/2024 5:46 PM, Lawrence D'Oliveiro wrote:
On Wed, 06 Mar 2024 14:30:58 +0000, aph wrote:
Continuously-compacting concurrent collectors like those available for
Java aim for less than 10ms, and often hit 1ms.
What ... a 1ms potential delay every time you want to allocate a new
object??
GC can be a no go for certain schemes. GC can be fine and it has its place.
On Sun, 3 Mar 2024 22:11:14 -0000 (UTC), Blue-Maned_Hawk wrote:
Lawrence D'Oliveiro wrote:
On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote:
I do not want to live in a web-centric world.
You already do.
That does not change the veracity of my statement.
That doesn’t change the veracity of mine.
On 06/03/2024 23:00, Michael S wrote:
On Wed, 6 Mar 2024 12:28:59 +0000
bart <[email protected]> wrote:
"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust keeps
track of who can read and write to memory. It knows when the
program is using memory and immediately frees the memory once it
is no longer needed. It enforces memory rules at compile time,
making it virtually impossible to have runtime memory bugs.⁴ You
do not need to manually keep track of memory. The compiler takes
care of it."
This suggests the language automatically takes care of this.
Takes care of what?Garbage collection does not stop heap fragmentation. GC does, I
AFAIK, heap fragmentation is as bad problem in Rust as it is in C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
GC-based languages like Java, C# or Go.
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the program
at any given time, and having larger heaps reduces fragmentation (or
at least reduces the consequences of it).
On 2024-03-07, David Brown <[email protected]> wrote:
On 06/03/2024 23:00, Michael S wrote:
On Wed, 6 Mar 2024 12:28:59 +0000Garbage collection does not stop heap fragmentation. GC does, I
bart <[email protected]> wrote:
"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust keeps >>>> track of who can read and write to memory. It knows when the program
is using memory and immediately frees the memory once it is no longer
needed. It enforces memory rules at compile time, making it virtually
impossible to have runtime memory bugs.⁴ You do not need to manually >>>> keep track of memory. The compiler takes care of it."
This suggests the language automatically takes care of this.
Takes care of what?
AFAIK, heap fragmentation is as bad problem in Rust as it is in
C/Pascal/Ada etc... In this aspect Rust is clearly inferior to GC-based
languages like Java, C# or Go.
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the program at
any given time, and having larger heaps reduces fragmentation (or at
least reduces the consequences of it).
Copying garbage collectors literally stop fragmentation.
Reachable
objects are identified and moved to a memory partition where they
are now adjacent. The vacated memory partition is then efficiently used
to bump-allocate new objects.
On 07/03/2024 17:35, Kaz Kylheku wrote:
On 2024-03-07, David Brown <[email protected]> wrote:
On 06/03/2024 23:00, Michael S wrote:
On Wed, 6 Mar 2024 12:28:59 +0000Garbage collection does not stop heap fragmentation. GC does, I
bart <[email protected]> wrote:
"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust
keeps track of who can read and write to memory. It knows when
the program is using memory and immediately frees the memory
once it is no longer needed. It enforces memory rules at compile
time, making it virtually impossible to have runtime memory
bugs.⁴ You do not need to manually keep track of memory. The
compiler takes care of it."
This suggests the language automatically takes care of this.
Takes care of what?
AFAIK, heap fragmentation is as bad problem in Rust as it is in
C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
GC-based languages like Java, C# or Go.
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the
program at any given time, and having larger heaps reduces
fragmentation (or at least reduces the consequences of it).
Copying garbage collectors literally stop fragmentation.
Yes, but garbage collectors that could be useable for C, C++, or
other efficient compiled languages are not "copying" garbage
collectors.
Reachable
objects are identified and moved to a memory partition where they
are now adjacent. The vacated memory partition is then efficiently
used to bump-allocate new objects.
I think if you have a system with enough memory that copying garbage collection (or other kinds of heap compaction during GC) is a
reasonable option, then it's unlikely that heap fragmentation is a
big problem in the first place. And you won't be running on a small
embedded system.
07.03.2024 17:36 David Brown kirjutas:
CPython does use garbage collection, as far as I know.
AFAIK CPython uses reference counting, i.e. basically the same as C++ std::shared_ptr (except that it does not need to be thread-safe).
With reference counting one only knows how many pointers there are to a
given heap block, but not where they are, so heap compaction would not
be straightforward.
Python also has zillions of extensions written in C or C++ (all of AI
related work for example), so having e.g. heap compaction of Python
objects only might not be worth of it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 38:30:13 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,381 |