←back to thread

Giving C a superpower: custom header file (safe_c.h)

(hwisnu.bearblog.dev)
271 points mithcs | 5 comments | 17 Nov 25 10:40 UTC | HN request time: 0.202s | source
Show context
woodruffw ◴[17 Nov 25 13:30 UTC] No.45953391[source]▶
Intentionally or not, this post demonstrates one of the things that makes safer abstractions in C less desirable: the shared pointer implementation uses a POSIX mutex, which means it’s (1) not cross platform, and (2) pays the mutex overhead even in provably single-threaded contexts. In other words, it’s not a zero-cost abstraction.

C++’s shared pointer has the same problem; Rust avoids it by having two types (Rc and Arc) that the developer can select from (and which the compiler will prevent you from using unsafely).

replies(13): >>45953466 #>>45953495 #>>45953667 #>>45954940 #>>45955297 #>>45955366 #>>45955631 #>>45955835 #>>45959088 #>>45959352 #>>45960616 #>>45962213 #>>45975677 #
1. spacedcowboy ◴[17 Nov 25 13:46 UTC] No.45953495[source]▶
The number of times I might want to write something in C and have it less likely to crash absolutely dwarfs the number of times I care about that code being cross-platform.

Sure, cross-platform is desirable, if there's no cost involved, and mandatory if you actually need it, but it's a "nice to have" most of the time, not a "needs this".

As for mutex overheads, yep, that's annoying, but really, how annoying ? Modern CPUs are fast. Very very fast. Personally I'm far more likely to use an os_unfair_lock_t than a pthread_mutex_t (see the previous point) which minimizes the locking to a memory barrier, but even if locking were slow, I think I'd prefer safe.

Rust is, I'm sure, great. It's not something I'm personally interested in getting involved with, but it's not necessary for C (or even this extra header) to do everything that Rust can do, for it to be an improvement on what is available.

There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc. You pays your money and takes your choice.

replies(3): >>45953615 #>>45955000 #>>45960408 #
2. woodruffw ◴[17 Nov 25 14:02 UTC] No.45953615[source]▶
That’s all reasonable, but here’s one of the primary motivations from the post:

> We love its raw speed, its direct connection to the metal

If this is a strong motivating factor (versus, say, refactoring risk), then C’s lack of safe zero-cost abstractions is a valid concern.

3. lelanthran ◴[17 Nov 25 16:18 UTC] No.45955000[source]▶
> As for mutex overheads, yep, that's annoying, but really, how annoying ?

For this use-case, you might not notice. ISTR, when examing the pthreads source code for some platform, that mutexes only do a context switch as a fallback, if the lock cannot be acquired.

So, for most use-cases of this header, you should not see any performance impact. You'll see some bloat, to be sure.

4. lmm ◴[18 Nov 25 01:33 UTC] No.45960408[source]▶
> There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc.

There really isn't. Speaking as someone who works in JVM-land, you really can avoid C all the time if you're willing to actually try.

replies(1): >>45977431 #
5. spacedcowboy ◴[19 Nov 25 09:12 UTC] No.45977431[source]▶
shrug horses for courses. I’m at that wonderful stage of life where I only code what I want to, I don’t have people telling me what to do. I’m not going to throw away decades of code investment for some principle that I don’t really care about - if I did care more, I’d probably be more invested in rust after all.

Plus, a lot of what I do is on microcontrollers with tens of kilobytes of RAM, not big-iron massively parallel servers where Java is commonly used. The vendor platform libraries are universally provided in C, so unless you want to reimplement the SPI or USB handler code, and probably write the darn rust implementation/Java virtual machine, and somehow squeeze it all in, then no, you can’t really avoid C.

Or assembler for that matter, interrupt routines often need assembly language to get latency down, and memory management (use this RAM address range because it’s “TCM” 1-clock latency, otherwise it’s 5 or 6 clocks and everything breaks…)