TrapC, a Year Later

An update on TrapC progress

Baltimore, MD (trapc.org) 26 January 2026 – About a year ago in February of 2025, I presented a whitepaper to the ISO C Committee meeting TrapC: Memory Safe C Programming with No UB. The White House had released its Building Blocks report in February 2024, calling for replacing C/C++ with memory safe languages such as Rust or Python. That generated some pushback from the C++ community, but there was no solid plan what to do about the treachery of C/C++ pointers and the crashes and exploits that result from pointer misuse.

It’s not as though nobody had tried to fix C and C++ memory issues. Memory safety had been a concern from the beginning of the C programming language back in the 1970s. However, despite many attempts over decades, nobody had found an elegant and efficient answer to the C/C++ memory safety problem.

In March 2024, as a member of the ISO C++ Committee, I attended the committee meeting in Tokyo, with 200 others gathering to define the C++26 standard. I had earlier presented TrapC as a concept, but many questions remained how to define TrapC implementation. That was my mindset in Tokyo, that I had a workable concept for memory safety, not all the implementation details necessary to build it. In Tokyo, the talk was about reflection templates and other C++26 proposals, not so much memory safety.

At the Tokyo meeting I met Khalil Estell who would later present at the CppCon keynote in September 2024: C++ Exceptions for Smaller Firmware. Khalil is a very interesting person because he understands embedded systems engineering from the standpoint of writing software foe ear buds, that is, really tiny programs. I’d designed safety-critical embedded Linux software that is national critical infrastructure, where the use of exceptions is banned. C++ exceptions are generally considered too slow and unpredictable for use in safety-critical systems, game servers and algorithmic trading systems.

Khalil and I talked for a long time. While I may never love exceptions, it was a stimulating discussion. C++ exceptions are too complicated for me even if Khalil makes them lightning fast. Discussing embedded exceptions made me think hard about how error handling could be simple and fast in C, not about C++. What if we could trap errors where they happen instead of making them seem exceptional and convoluted? Eliminate the complexity and the overhead of the exceptions return stack.

By the close of the ISO C++ Committee meeting I realized that the committee felt no mandate to fix C++ memory safety issues. Because it’s not their problem. The trouble with pointers is actually a C programming language issue that C++ inherited by demanding C backward compatibility. If I was to fix pointers somehow, I would need to do so in C. From that starting point came my white paper to the ISO C Committee. After feedback from the committee, I made a few tweaks to the design, but my whitepaper is still a pretty good guide to the TrapC extension. The most vociferous feedback was I had to make TrapC fully backward compatible with compiling ANSI C code, to not break legacy codebases.

My work building TrapC has taken two parallel paths. A TrapC interpreter called itrapc and a separate compiler called trapc. I had wanted to make a software release by 1 January 2026, but too many bugs. I only reached code complete this month and am now on the painstaking and sleepless process of debugging. When I have something stable that mostly works I will make a release. Sorry to make you wait a little longer.  Aiming for Q1 2026.