Hacker News Reader

Comment by jnwatson | Hacker News Reader

The problem with the safe C subsets is that it means you have to write new code. But if you have to write new code, why would you do it in C?

View on HN

You wouldn't - you'd write it in the safe C subset?

Presumably it's easier to rewrite part of your app rather than the whole thing.

But I'm all for a safe version of C17 (or C23/24). It's so disappointing that there isn't a standard memory-safe compiler/runtime/ABI. (And while they're at it, the stack should grow up rather than down.)

Perhaps CHERI or similar will catch on someday. Maybe Apple could try implementing memory checking for clang and Apple Silicon.

I am currently working on a GCC frontend that has a memory safe mode where it would warn about every unsafe constructs. At the same time a trying on modifying some of my projects to work with it. To me, this seems an entirely reasonable approach. But it is a spare time project, so progressing slowly.

A bit unfair. It verifies a subset of C because it is incomplete.

It looks as though the idea is that you can annotate existing code, which is a lot easier than rewriting.

You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in actually safe language.

> You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier

That's not necessarily true though.

Half decent C code already has a coherent memory management strategy. The problem is that humans can't follow even pretty straight-forward memory management strategies 100% of the time. If you have a function that returns memory the caller is required to free, or accepts a parameter that the function takes ownership of, that can be easily expressed but hard to get right every time.

In fact, functions typically document this... in half-decent C code. So we're really talking about formalizing the expression of memory management documentation that already exists and is already understood.

> And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in actually safe language.

I just can't think of what the rational argument for this could be. A complete deep rewrite -- where the new language requires reorganizing the code at a low level so that a lot of existing logic cannot be reused (as-is, or transformed in certain specific ways) -- is extremely costly. It is on the order of the total cost of writing the software in the first place plus the entire cost already spent maintaining it over time. Some costs -- like the goodwill of users/adpoters -- simply cannot be paid again at the same rate. For large scale software there would be numerous regressions over a long period of time, while at the same time the software stops adding many new features, since all the focus will on the rewrite and bugs related to the rewrite. I will stand corrected if there is more than one or two exceptional cases of large scale software making a successful transition of this sort without paying a massive cost.

If you don’t understand the code well enough to annotate it, it seems hard to believe you’d able to rewrite it and end up with the same functionality (same processing rules, accepts identical input, produces identical output, etc).

You certainly could get the same level of safety via annotations as you can in safe language. And if you transition existing code, you do not need to rewrite that will introduce new bugs and invalidate all the testing.

>> understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in

But rewriting assumes I learn a new language on top of rewriting.

It's still better than a complete rewrite, which will very likely introduce new bugs that had already been fixed in the existing code (no matter what languages are used).

As someone who tried to get Frama-C working on existing code: No, annotating existing code is not much easier than rewriting it. In fact, to make these annotations practical, I had to rewrite parts of the code anyway.

A lot of times, C is the only option, for example in embedded scenarios where the vendor's C compiler is the only way of compiling for that platform.

That just means you need a whatever-to-C transpiler. Which in most cases is quite achievable, and especially so if the language is designed to allow that (so e.g. no guaranteed tail call optimizations etc).

The problem with black-and-white thinking is that it's too simplistic to apply to the great majority of real-world problems.

Safe C provides an incremental migration path from unsafe C to safe C. And you don't need to completely rewrite, but instead address the issues flagged, which will often be a lot less work and risk than an actual rewrite in a new language. (This seems obvious to me, but apparently not?)

This is our thinking as well, a complete rewrite in another language (short of formally verifying the code) could introduce all sorts of logical bugs that did not exist or were patched in the old code.

Most of the proposals I've seen so far work via annotating existing code, not complete rewrites (e.g. here's one example from Apple: https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...)

Annotating, possibly incrementally, existing code would be way easier than a rewrite.

Safety annotations is the directions that C++ has been attempting without much success for a while though, so I'm not very optimistic. But I'm always happy to see another attempt.

It could be helpful if the annotation can be stripped out if needed for use with older compilers (especially important for older microprocessors that won't ever have it's C compiler ported).

Xr0 currently works this way, the annotations can be stripped out with a "-s" flag (See here https://xr0.dev/learn#compiling)

If you don't like C, you don't need to come into threads about C. HN is not for ideological battle.

Would you go into a thread about emacs and say, "Why would anyone use emacs over vi?" And if not, what makes you think you should do that here?

I understand both perspectives. The premise should be questioned, a correct amount. "Do not question our premise" is a weird take.

I'm not objecting to "the problem with the safe C subsets...."

I'm objecting to the disdainful "why would you do it in C?"

You didn't ask him to clarify, you asked him to leave.

I don't see any need to clarify. What do you believe requires clarification?

Despite being 2024, there's still has not been any progress on taste.

There's been regress!

Less ceremony than Rust (and no ball-breaking fighting the borrow checker), a lot faster than Go, way more mature than Zig, and with more immediate compatibility with tons of code, more support, more developers, and more mature compilers than any of the above.

Reply on news.ycombinator.com