5 ms·
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?
by jnwatson 3y ago
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?
- flohofwoe 3y agoMost 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-c-fbounds-safety/70854 https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...)
- gpderetta 3y agoAnnotating, 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.
- graemep 3y agoA 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.
- muldvarp 3y agoAs 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.
- KerrAvon 3y agoYou 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.
- uecker 3y agoYou 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.
- awaythrow999 3y ago>> 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.
- flohofwoe 3y agoIt'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).
- jmull 3y ago> 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.
- infamouscow 3y agoDespite being 2024, there's still has not been any progress on taste.
- shrimp_emoji 3y agoThere's been regress!
- ironmagma 3y agoA 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.
- int_19h 3y agoThat 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).
- deleted 3y ago[deleted]
- mofosyne 3y agoIt 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).
- betz47 3y agoXr0 currently works this way, the annotations can be stripped out with a "-s" flag (See here https://xr0.dev/learn#compiling https://xr0.dev/learn#compiling)
- coldtea 3y agoLess 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.
- jmull 3y agoThe 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?)
- betz47 3y agoThis 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.
- torstenvl 3y agoIf 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?
- musicale 3y agoYou 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.
- uecker 3y agoI 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.