[libre-riscv-dev] offtopic: memory safety

[Jacob Lifshay]

On Wed, Jul 17, 2019, 13:37 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wed, Jul 17, 2019 at 9:22 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > I found a great article about what memory safety means in languages like
> C,
> > C++, and Rust, describing why "what the hardware does is not what your
> > program does":
> >
> https://www.reddit.com/r/rust/comments/cd522f/what_the_hardware_does_is_not_what_your_program/

one of the parts I found interesting is the linked-to research paper on
redesigning undefined behavior in llvm -- discarding undef in favor of
poison and introducing freeze().

>
>
>  as someone who was brought up on systems-level programming (samba,
> freedce, apache2), i am staggered beyond belief at the level of
> complete incompetence and ignorance that seems to be spreading, which
> even *requires* these kinds of posts.
>
:)

 The second programming language that I learned is C, shortly followed by
C++ and x86 assembly language. (My first was QuickBASIC simply because it
was available on the windows 98 install disk.)

Before I found out about Rust, I was interested enough in C++ that I read
the spec through multiple times.

 of even deeper concern is that they're used to justify one language
> over another for completely inappropriate purposes.
>
yeah. though it is nice to have a programming language that is designed to
help you avoid UB, without needing extensive experience to get it right --
such as Rust (just don't use the unsafe kw), Python, Java, and others.
C (and C++) is powerful, but it's easy to mess up without extensive
experience -- I've worked on commercial production firmware where all the
non-reenterant file system code was called from the USB interrupt without
any kind of mutex, disabling interrupts elsewhere, or similar. that same
codebase used global variables modified by interrupts without using
volatile (pretty much the one spot other than memory-mapped hw where
volatile is the correct tool). They relied on optimizations not being ran.
I've even seen code that uses memset to initialize std::string after
running the constructor!

 certain classes of problem (certain classes of services) *require* a
> deep understanding of both that service *and* the hardware *and* the
> OS on which it is running *and* the compiler, and if you do not have a
> full understanding of all of those, there is simply no getting round
> any of those requirements by "picking an alternative language that's
> quotes better quotes".
>
>  in the case of the samba team "leaders", they simply genuinely had no
> idea - and no respect for - the dual nature of the two OSes that they
> were working with (windows *and* unix).  it was too much for them, and
> they made - repeatedly - poor design choices as a result.
>
hopefully they've been refactored since then.
In the mean time, one can vainly hope that microsoft switches windows to
using unix and deprecates the weirder parts of win32 -- apple did when they
introduced OS X.

>
> there's a rather long ongoing thread on comp.arch about undefined
> behaviour, where several extremely experienced programmers are
> participating.

interesting, will have to take a look.

Jacob