Posts by fg_swe

The Rust Foundation gets ready to Rumbul (we're sure new CEO has never, ever heard that joke before)

Re: Mutexes in C and C++

That is certainly an improvement, but it does not stop the programmer to accidentally share "normal" variables between threads.

For example, multiple threads can read and write a global variable in C and C++. Compilers will not even warn the programmer. Static analyzers *might* be able to detect and warn.

In more complex cases (object trees, handing pointers from one thread to another), these static analyzers quickly reach their limits and might not report this type of bug.

With Sappeur and Rust, global variables must be either synchronized (being protected by an internal mutex) or the compilers will emit an error. And also all other cases of "pointer passing" between threads are secured by means of the type system and its rules.

Mutexes in C and C++

I am fully aware of things like pthread_mutex, as I am using them in generated Sappeur code. But the C and the C++ compilers cannot determine whether the software developer has properly used these synchronization mechanisms. C and C++ have no means of differentiating between thread-local and thread-global data structures.

In Sappeur and Rust, you as the software engineer are forced to make this distinction and then the compilers insert synchronisation primitives as required.

There are static analyzer tools for C and C++, which attempt to do similar things, but I suspect they cannot do this in the same strict fashion.

Re: "Reference Counted"

https://security.business.xerox.com/de-de/news/wind-river-vxworks-ipnet-tcp-ip-stack-vulnerabilities/

C Memory Issues

When valgrind was first used to check the standard Unix userland tools (grep, wc, sed etc), it found plenty of memory errors. They resided in these programs for decades. From that "follows" that all Unix developers were "rookies", if you believe the C fanbois. In my opinion, it just demonstrates the limits of ANY human programmer.

I am not a big fan of Java either, but Java will immediately report an index error or a null pointer. C programs often "march on with several bullets sticking in the foot". An immediate Segfault is actually a very good thing, much better than hidden memory corruption.

Similar to the Unix tools at the time of valgrind introduction, many real-world Java log traces are full of exception traces, because the programs have not been properly developed/tested to maturity. But that is not the fault of Java, but rather the fault of the teams, managers, companies developing said Java-based systems.

What you can blame on Java itself is huge memory consumption (2x that of the equivalent Sappeur program), long startup times of the VM (Sappeur programs can start in a few milliseconds), and unpredictable delays due to GC mark+sweep runs.

Multithreaded Memory Safety ?

Boost may be a powerful library, it cannot ensure that multiple threads access shared data structures in a safe way. The type system of the compiler itself must support this.

The resulting bugs of accidental sharing are in many cases impossible to track down with a debugger. All you will see are heap corruptions at random places. Valgrind/Purify won't help you with that either, as they slow down runtime to a crawl, thereby often masking the bug.

Rust and Sappeur enforce safe access of multithreaded data.

Re: "Reference Counted"

HPUX Ping of Death ?

VxWorks TCP Datagram of Death and Subversion ?

The C language itself is a brittle, dangerous thing. Listen to Sir Tony Hoare (see my other post) or to Niklaus Wirth.

Re: Java Popularity

In any useful multithreaded program, the threads need to communicate with each other. For example, they need to update a shared hash table. They must NOT accidently share variables, buffers etc.

Rust and Sappeur enforce this through the type system. Shared data structures are protected by mutexes.

Re: "Reference Counted"

I kindly ask you to read here

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

https://www.chromium.org/Home/chromium-security/memory-safety

So both Google and Microsoft have come to the same conclusion.

Before you crow "Linux", I would like you to explain all of the exploitable kernel bugs, such as the one in gethostbyname(). The kernel developers are all rookies, eh ?

Java Popularity

Java's key feature is Memory Safety. This enables programmers and software engineers to quickly track down most of bugs to their root cause. With C and C++, you can have very nasty and (especially in multithreaded programs) nondeterministic bugs. Very hard and very expensive to track down and fix.

Time == Money.

Re: Reliable near zero latency

Rust, Swift, Sappeur have heap object reference counting and memory safety.

Re: Someone have to say it

You can have essentially identical semantics with indentation and semicolons. What matters in the case of Rust and Sappeur is not the semicolons, but type systems which assure memory safe operation and deterministic crash.

Details of Reference Counting

If the language's type system can differentiate between thread-local and inter-thread data structures, then thread-local reference counting does not need atomic operations. Atomic operations (which synchronize multiple CPUs/cores) is much more expensive in terms of runtime.

In my language Sappeur this is exactly how it is done.

"Reference Counted"

I was using a quick expression for "program using heap memory objects, which have a reference count. When reference count goes to zero, destructor will be called."

Better ?

Yeah, Cynicism

That will surely help you improve the state of the art. Not.

Once again:

1.) Wife gives programmer hell

2.) Programmer has cloudy mind

3.) Programmer makes rookie mistake due to 2.

4a) Rust compiler detects mistake

OR

4b) Rust runtime will detect problem and stop execution.

With C and C++:

4.) Mysterious faults, always at a different place.

Garbage Collection

All the GC-based languages I have seen in the real world suffer from

A) non-deterministic runtime, because the GC mark+sweep can hit at any time. This is bad for GUI ergonomics and other realtime applications.

B) High RAM consumption. GC-based programs consume typically 2x the amount of RAM of an equivalent reference-counted program. That translates in higher energy consumption (read CO2) and higher capital costs.

Re: Congrats

All programmers and software engineers are just fallible humans. They have families, managers, relationships. All of that can create pressure which will result in nasty software bugs.

It happened to HPUX, Linux kernel, Windows kernel and many other systems.

Re: Someone have to say it

Maybe you can put your syntactic desires on the backseat and appreciate the advanced type system of Rust. It will help you avoid or detect errors in a deterministic fashion, ideally at compile time.

Semantics is usually more important than syntax in computer science.

Re: about that steeper learning curve...

Fortran is lacking memory safety and according to Tony Hoare real-world Fortran programs have serious "hidden" index error problems. Deterministic detection of index errors is a key aspect of memory safety.

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

Problems of C and C++

Rust has been specifically created to address the serious weakness of C and C++ - a lack of memory safety.

Memory safety has many aspects. On page 2 of this presentation they are listed: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf