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

As a member of the ISO C++ Committee, I attended their meeting in Tokyo in March 2024, with 200 other attendees gathering to define the C++26 standard. I had presented TrapC as a concept, but many questions remained how to define TrapC implementation. That was my mindset in Tokyo, but the talk there was about reflection templates and other C++26 proposals, not memory safety.

At the Tokyo meeting I met Khalil Estell who would present the CppCon keynote in September 2024: C++ Exceptions for Smaller Firmware. Khalil was a very interesting person because he understood 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 considered too slow and unpredictable.

Khalil and I talked for a long time. While I may never love exceptions, it was a stimulating discussion. C++ 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 end of the ISO C++ Committee meeting I realized that the committee felt no mandate to fix C++ memory safety. 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.

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.