Here is a real safety issue that I found and fixed a couple weeks ago. This is an ancient language runtime which originally ran on MS-DOS, Amiga, Atari, and at least a dozen now-discontinued commercial Unices. I've been porting it to 64-bit OSes as a weekend hack. While this particular issue is unlikely to appear in modern applications, a similar pattern might manifest today as a use-after-free error with std::string_view or an invalid iterator.

Background:

    typedef int Text; 

const char *textToStr(Text t) - This takes a Text value and returns a pointer to a null-terminated string. If t is a string intern index, then it returns a pointer to the stored string. If t represents either a generated dictionary or generated variable name, then it calls snprintf on a static buffer and returns the buffer's address.

Problem:

The use of a static buffer in textToStr introduces a temporal safety issue when multiple calls are made in the same statement. Here’s an excerpt from a diagnostic error message, simplified for clarity:

    printf(stderr, "Invalid use of \"%s\" with \"%s\"",
                textToStr(e),
                textToStr(s));

If you want anyone to believe you, you're going to have to give more than just a blank assertion. Can you give at least a sketch of your reason for your claim?

Well, ignoring all the reports from google, microsoft and mozilla, all of whom are part of a cabal spreading misinformation on the percentage of vulnerabilities caused by memory unsafety in C++ (all 3 arrived at around 70% so it's clearly a made up number they colluded to spread), and ignoring the reports from the United States government (probably infiltrated by rust cultists), I can recommend the paper Memory Errors: The Past, the Present, and the Future

>As an old-timer, I think you have some serious misconception about how RAII works, and what it does for you.

I appreciate the education :-)

>There's nothing that stops you from using arena allocators in C++.

This is true, but arenas have two wonderful properties - if your only disposable resource is memory, you don't need to implement disposal at all; and you can free large numbers of individual allocations in constant time for immediate reuse. RAII doesn't help for either of these cases, right?

>Use of destructors leads to use of destructors

I guess what I mean is... It's totally possible and common to have a zillion copies of std::vector in your binary, even though the basic functionality for trivially copyable trivially destructible types is identical and could be serviced from the same implementation, parameterized only on size and alignment. Destruction could be handled with a function pointer. But part of the reason templates are used so heavily seems to be that there's an expectation that libraries should handle types with destructors as the common case.

>lifetime management is a huge problem in C. Not at all trivial to clean things up when you're done.

Absolutely true if you're linking pairs of many malloc and free calls. But if you have a model where a per-frame or per-request or per-operation arena is used for all allocations with the same lifetime, you don't have this problem.

>And C's behavior would also be "UB" if you read after freeing a pointer.

The specific issue I ran into was the destructor of one thread_local reading the value of another thread_local. In C++17 the way to do this was to make one of them trivially destructible, as storage for thread locals is released after all code on that thread has finished, and the lifetime for trivially destructible types ends when storage is freed. In C++20 this was changed, such that the lifetime of a thread local ends when destroyed (rather than when storage is freed) if it's trivially destructible. C thread local lifetimes are tied to storage only and don't have this problem.

You can use `unique_ptr` with a custom deleter for wrapping C libraries.

  using snd_pcm_T = std::unique_ptr<
    snd_pcm_t,
    decltype([](void* ptr){snd_pcm_close(ptr);})
  >;
  auto pcm_handle = snd_pcm_T(snd_pcm_open(...));

Sure pal, in an imaginary world where:

Apache/nginx don't exist,

Chrome/V8 don't exist,

Firefox doesn't exist,

GCC/Clang don't exist,

MySQL doesn't exist,

TensorFlow doesn't exist,

VLC doesn't exist,

and the list goes on and on ...