To kill memory safety bugs in C code, try the TrapC fork

Memory-safe variant is planned for next year

Exclusive C and C++ programmers may not need to learn Rust after all to participate in the push for memory safety.

Speaking remotely at the W2140 conference in Bangkok, Thailand, on Tuesday, Robin Rowe, a former computer science professor, product designer, and graphics expert, plans to announce a fork of the memory safe fork of C programming language called TrapC. Its goal is to help developers create software that can't crash.

TrapC code resembles C/C++ code, but, according to Rowe, it's memory safe. That is to say, its pointers cannot produce segfaults, buffer overruns, or memory leaks. The programming language is designed to be link compatible with C, because it uses the same application binary interface (ABI). And supposedly it's safer than Rust because it lacks an "unsafe" keyword while also being easier to learn.

The TrapC compiler is due to be released as free open source software in 2025, through Rowe's startup, Trasec, which will support the forthcoming memory-safe C-adjacent language and at some point will have a website associated with its domain name.

"Back in February, the White House announced that we needed to do something about memory safety in C and C++ or change over to Rust," Rowe told The Register.

"And at the time, I was a member of both the C and C++ committees and, as you can imagine, this caused quite a stir in that corner."

There was a huge discussion within the C and C++ communities because neither language is memory safe and there's skepticism that they can be made so. The Safe C++ proposal was one of the responses from the C++ community.

According to Rowe, Bjarne Stroustrup, creator of C++, said he had been working on Profiles [PDF] and wanted to continue doing so.

"And I love Bjarne, but I don't think Profiles are the right answer," said Rowe. "And in the C community, the answer was even less [clear]. There wasn't really a plan of what to do."

Doing something to improve memory safety has become a matter of national security, supported by the White House, the Five Eyes intelligence agencies, federal law enforcement, and the US Cybersecurity and Infrastructure Agency, among others. Memory safety bugs account for about 75 percent of the CVEs used in zero-day exploits, according to Google. And about 70 percent of severe vulnerabilities in large codebases are attributable to such bugs.

C and C++ are common sources of memory safety bugs because they rely on manual memory management. The benefit, generally speaking, is better performance and less overhead than languages like Python or Java that manage memory through a process known as garbage collection. The downside of manual memory management is that it can lead to memory-related bugs like buffer overflows and use-after-free.

"Then in March, I was in Tokyo at the C++ standards group meeting," said Rowe. "And of course, [memory safety] was still being discussed there, although people had many other things that they were working on. And so I got to thinking about it and I was like, 'Well, the reason it's so hard to fix C++ is backward compatibility with C.'"

Rowe said that the biggest memory safety holes in C++ were inherited from C. "So there was discussion at the March meeting about how to improve exceptions so that C++ could have better error handling." Exceptions are a mechanism for error handling in code.

Developers of games, embedded systems, and high-availability servers typically ban using exceptions because they're non-deterministic and have other performance-related issues, explained Rowe.

"The places that need to be the most error-proof are the places that see those exceptions are banned," he said. "And so I looked at some of the work that was going on there and said, 'Well, instead of trying to fix that, what if we would just change how error handling works so that errors are tracked by default instead of by exception?'"

Presently, in C and C++, if you try to open a file and don't code an error condition to handle what happens when the file doesn't open, the program will probably crash, explained Rowe.

But it doesn't have to be that way. "What if, say, you go to open a file in C and if you don't say what happens when the file doesn't open, then that creates some kind of error condition that gets implicitly called?" he said.

That, he said, got him thinking about memory management, which is what everyone's concerned about.

"People said that we can't do memory, we can't check pointers in C++, because it's too hard," he said. "And they didn't actually mean it was too hard, they just meant that it was too slow. They meant it was too hard to do it well."

Rowe's answer to this is to put more intelligence into the compiler so that where unchecked pointers could not go out of bounds, the compiler knew not to check that. And that improved performance by avoiding unnecessary checks.

"And then I thought, 'Well, since the compiler now knows when pointers are OK, what if the compiler would null any pointer that goes out of bounds?'" he said.

"So in C and C++, if you have a pointer to a buffer and you plus-plus it, you increment it forward, at some point you go off the end and if you're not careful to check that you've gone off the end, that's going to be a segfault or something terrible.

"And I was like, 'Well, since the compiler knows where the end is, what if when it goes off the end, the pointer just went to zero?' And that's much easier to deal with than a wild pointer because you can easily check if the pointer is zero.

"And so that's the essence of what we're working on with TrapC, to create this C-like language where everything looks pretty much the same except pointers work in a fundamentally different way that is mostly transparent. And error handling works in a way that is fundamentally different but mostly transparent."

Rowe's experience with the C++ committee, which oversees proposals and approves changes, led him to believe that pushing memory safety changes through the existing bureaucratic process would take too long.

After proposing a GUI library for C++, he said he was advised to join the committee and write a paper. When he joined, "several people that were old hands of the committee wrote to me that I didn't really know them but they were trying to take me under their wing and said, 'Just understand that it takes ten years to approve anything in the committee.' You know, they were really selling me on it."

Rowe said that after being on the committee and interacting with a lot of smart people, "I was like, 'Wow, I can actually see a clearer way to fix this problem than everyone else thinks can't be fixed.'"

The reason TrapC is a fork of the C language rather than a proposal run through committee is that Rowe doesn't think we can afford to wait a decade for the bureaucratic process to work its magic.

So here we are. And here's an example of TrapC code:

// darpa_tractor.c

int main(int argc,char* argv[])
{   char buff[8]; // TrapC implicitly zeros, no dirty memory    
        int success = 0;// In C, buffer overwrite corrupts success    
        strcpy(buff,argv[1]); // TrapC cannot overrun, strcpy safe    
        if(!strcmp(buff,"s3cr8tpw"))
        {       success = 1;    
        }    
        if(success) // TrapC blocked strcpy overwrite, success good    
        {       printf("Welcome!\n");    
        }      
        return !success;
}

// trapc_ptr.c

int main()
{   const char* ptr = "Hello World"; // 12 char wide    
        while(ptr) // No buffer overrun with TrapC 
        {       printf("%c",*ptr); // print one char at a time 
                ptr++;  // Steps off the end: TrapC nulls ptr!
        }  // Do NOT attempt this in C, will segfault!
        assert(ptr == 0);    
        return 0;
}

// trapc_array.c

        int score[10]; 
        printf("%i",score[-1]); // TrapC will not allow access
        for(int i = 0;i <= INT_MAX;i++) // C Undefined Behavior
        {  printf("%i",i);
        }
        // In C, above code is an infinite loop, will not stop.  
        // TrapC blocks i++ overflow wrap-around, stops.
        // TrapC will fail-safe, call error handler if defined.

Much of Rowe's thinking about TrapC was guided by the requirements of writing for embedded systems.

"I worked on safety-critical embedded systems for the traffic control system for the country," said Rowe. "I wrote Linux real-time software in C++ that controls traffic lights in the US. And so a lot of my thinking was shaped by that, because when you're doing safety-critical embedded systems in C++, you don't use exceptions, obviously.

"You also try to avoid inheritance, definitely no movable inheritance, try to stay away from templates, try to stay away from operator overloading.

"Just a lot of the features that people think make C++ cool or maybe too complicated depending on who you're talking to. In safety-critical [programming], we just don't do it because we have to be very meticulous and careful that we haven't forgotten something.

"That really guided me. In TrapC, I was like, well, the thing that I use from C++ and embedded systems that I don't have in C is constructors and destructors. So TrapC actually has C++ constructors and destructors. And that's also something that I could never get approved in the C language, not even with ten years of lead time."

But TrapC isn't just for embedded systems, said Rowe. It's for everything.

"TrapC actually has fewer keywords than C does by just a little bit because I've taken out union and some other things that I rarely use that tend to cause problems and you probably wouldn't use it in a safety-critical system anyway," he said. "And TrapC has the same ABI as C. So if you want to do something unsafe, you can write it in C and link to it. And this is a big difference from Rust where you have the unsafe keyword saying, 'Well, you know, I give up, I'm not going to be safe here.'"

Rowe's pitch to developers is simply that if you want to learn a different language, go for it.

"I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."

For those who know C, there shouldn't be much of a learning curve.

"C is so close that many things will compile as is," said Rowe. "Where you see a big difference is TrapC doesn't have malloc. TrapC has new, like C++ does. And so you need to change all your malloc calls. But TrapC doesn't have delete. TrapC does the memory. There's no memory leaks in TrapC because the compiler handles free memory. Also, in that way, it's like Java. Java you call new, but you never call delete."

Rowe said he believes TrapC obviates the need for DARPA's TRACTOR program, an effort to develop C to Rust conversion tooling. "I just sent an email to the program manager for TRACTOR and told him that maybe he doesn't need to do that," he said. "But I don't know how much he's going to welcome that message."

Rowe intends to serve as CEO of Trasec and company co-founder Gabrielle Pantera, a former Disney executive, will serve as COO. The next step is to raise funds for the venture.

"The business plan is to give the compiler away as free open source and to have an AI IDE that's our paid product," he said. "So the thinking is that with our IDE, it'll create the frameworks for you so you have a nicely object-oriented structured program and have the AI be able to write the code snippets. Because today, when you build stuff, when you try to do generative AI programming, it can be too much spaghetti. It's not nicely structured the way that you would like. It definitely doesn't give you the unit test. And our system gives you the unit test for the rest of it."

Rowe also intends to create a foundation called Fountain Abode to manage the TrapC language definition and publication. It's slated to be overseen by Rowe and Pantera.

"We want it to run everywhere," said Rowe. "On every platform, on every architecture. The idea is that this is a memory-safe fork of C. And because it's a fork, if you know C, you're 95 or 99 percent of the way there. There's very little to learn." ®