Future of memory management in D

[H. S. Teoh]

On Wed, Nov 17, 2021 at 01:23:38AM +0000, forkit via Digitalmars-d wrote:
[...]
> Nothing can compete with C, in terms of being the layer just above assembly.
> 
> Many try. All fail.
> 
> Improving on D's capability to write and interop with low-level code,
> seems like a worthwhile exercise to me, as it expands the problem
> domains in which D can be used.
> 
> But that is a very different objective to being C's successor.
> 
> C will always B.

Until buffer overflows, stack corruptions, and other lovely security
holes thanks to C's unabashedly unsafe and outdated language constructs
make it irrelevant in a world where security is quickly becoming (if it
hasn't already become) a primary concern.


Recently at my job I was assigned to review code quality issues found by
an automatic code analysing tool in a very large C codebase.  From
reviewing (and fixing) hundreds of them, I can confirm that Walter was
100% spot on when he talked about design problems in C, the worst of
which are the memory-safety issues.  Some of the top issues I've
encountered are:

- Uninitialized variables (i.e., there's a code path that leads to
  reading an uninitialized variable), the worst of which is
  uninitialized pointers.

- Dereferencing of null pointers (forgetting to check for null, or using
  a pointer *before* checking for null -- don't laugh, this happens
  *very* often even with the most seasoned C programmers; the code path
  that triggers this is usually completely non-obvious after a function
  has been revised several times).

- Resource leaks (most frequent: memory leaks; after that file
  descriptor leaks, then other resource leaks).

- Buffer overflows / overruns (unterminated strings being the most
  common). The worst offenders are functions that take a pointer to an
  array without a size parameter and just *assume* that there's enough
  space (oh yes, people still write such monstrosities -- a LOT more
  than you might think).

- Double free.

99.9% of these issues are latent bugs: the usual code paths don't
trigger them so nobody realizes that the bugs are there.  But given some
carefully-crafted input, or some environmental factors (disk full, file
not found, different operating environments, etc.), these bugs will
manifest themselves.

Sometimes these bugs *do* cause things to blow up in a customer
deployment environment, and cost us a LOT of money to clean up and fix.
Not to mention the countless hours of employee time spent chasing down
and fixing these bugs -- and the wages paid that could have been spent
on things like actually implementing new features and making progress.

And 90% of these issues are completely non-obvious to code reviewers
(among whom are some of the best C programmers in our team).  These are
not bugs caused by clueless n00bs; these are bugs that sneak into code
written by seasoned C coders with decades of experience **because the
language is inherently unsafe**.


One day, the realization will dawn on decision-makers that using such an
outdated language in today's radically different environment from the
70's when C was designed, is a needless waste of resources. And then the
inevitable will happen.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond