Re: Development Speed

[xenodasein]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02457.html
From: Eli Zaretskii

> Not -std=c17, -std=gnu17. We need some extensions, and cannot compile
> with __STRICT_ANSI__ defined (which is what -std=c17 does, AFAIK).

But we are also restricted to some subset dialect of it, not to break
older settings, right?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02453.html
From: Stefan Monnier

>> Language would help with this, I think.
> I don't think so. Such cruft is just the result of having to change
> code you don't know or understand enough to be sure exactly what to do,
> so you write your change so as to preserve as much of the previous
> behavior to be on the safe side. Language doesn't come into the picture
> very much. Test suites and "memory" (e.g. having the original author(s)
> around) do to some extent.

It is helpful to know what dialect you are dealing with when refactoring
such code, in terms of understanding and not causing new bugs.  Newer
language features might also help.  Of course other things mentioned
are a lot more significant:
> Language doesn't come into the picture very much.

But I guess this is getting too abstract, better for me talk over
examples when I'm over more of the code.

> There isn't much code in Emacs which suffers from UB, as far as I know.
> That code is quite crucial, OTOH (it's typically the bit-twiddling we
> use to manipulate the tagbits of `Lisp_Object` and the conservative
> stack scanning): I don't know how to write this without going outside of
> the specs of C (or Rust for that matter).

I see.  I wouldn't consider this "UB", I mean it literally is but when
it is intentional, functional on all targeted platforms, documented
and localized, it is just normal practice.  What I meant was of course
the unintended ones.

>> I had heard of studies showing how most bugs in important
>> C software were resulting from UBs, i.e. having wrong assumptions
>> on what you write
> [ Never heard of such studies. ]

>> Hell, didn't they invent Rust just to avoid these issues?
> Not that I know, no. It had to do with avoiding memory management and
> concurrency bugs, as far as I know. And yes I have heard of studies
> that showed that memory safety and concurrency are the most common
> sources of bugs in C-style languages.

Hm.  So, memory safety and concurrency mistakes in most cases do not
stem from "having wrong assumptions on what you write?"

Perhaps I should work on my wording to legally prove what I thought
a lot more clearly if some things I write here will get literal answers;
or get taunted.