Re: Development Speed

[Stefan Monnier]

>> If you describe a concrete problem linked to being "not C17 compliant",
>> then maybe we can start thinking about a plan.
> 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.  ]
It's definitely not the case that most of the bugs we fix in Emacs
result from UB.

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).

> 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.

>> But so far all I've seen is "compliance for its own sake".
> Even when it made zero technical improvements, it would make soft
> improvements especially for future.

Given that I still don't know of any place in Emacs's C code where we're
not compliant, I'm not sure that's the case.

>> ... - The cruft accumulated over the years. ...
> 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.

>> I don't even know of any single place where we're not "C17 compliant".
> I'm confused, does this mean it is possible to fully build Emacs
> with "-std=c17"?

I'd assume so until proven otherwise.


        Stefan