Live data from Hacker News

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

hwisnu.bearblog.dev

211–220 of 277 posts

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

#211
post #52

Earlier quoted context omitted.

Because about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety. People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great…

> Because about 99% of the time the garbage collect is a negligible portion of your runtime lol .. reality disagrees with you. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf#:~:te... On page 3 they broadly conclude that if you use FIVE TIMES as much memory as your program would if managed manually, you get a 9% performance hit. If you only use DOUBLE, you get as much as a 70% hit. Further on, there are compre…

Methodology seems kind of dubious:

> We introduce a novel experimental methodology that lets us quan- tify the performance of precise garbage collection versus explicit memory management. Our system allows us to treat unaltered Java programs as if they used explicit memory management by relying on oracles to insert calls to free. These oracles are generated from profile information gathered in earlier application runs.

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

#212
post #68

Earlier quoted context omitted.

> Because about 99% of the time the garbage collect is a negligible portion of your runtime In a system programming language?

Yes, plenty have been done already so since Lisp Machines, Smalltalk, Interlisp-D, Cedar, Oberon, Sing#, Modula-2+, Modula-3, D, Swift,.... It is a matter to have an open mindset. Eventually system languages with manual memory management will be done history in agentic driven OSes.

"Agentic driven OSes"? Sounds like AI hype babble.

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

#213

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…

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…

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

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

#214

Earlier quoted context omitted.

Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)

I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025. I have never seen a language with a better ffi into C than C.

> the massive, well-maintained set of critical libraries upon which UNIX is based

What massive, maintained set is that? Base Unix is tiny, and any serious programming ecosystem has good alternatives for all of it.

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

#215

Earlier quoted context omitted.

Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)

> Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. Maybe; I sometimes write non-hobbyist non-performance-critical code in C. I'm actually planning a new product for 2026 that might be done in C (the current iteration of that product line is in Go, the previous iteration was in Python). I've few qualms about writ…

> I've few qualms about writing the server in C.

Why are you not worried about becoming the next Cloudbleed? Do you believe you have superhuman programming abilities?

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

#216
post #129
post #78

Earlier quoted context omitted.

Embedded CPU vendors not shipping C++ compilers is what usually stops people.

Yup. And I like the implication that Rust is 'cross platform', when it's 'tier 1' support consists of 2 architectures (x86 & arm64). I guess we're converging on a world where those 2 + riscv are all that matter to most people, but it's not yet a world where they are all that matter to all people. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html

You are misunderstanding what Tiers are. Embedded architectures cannot be Tier 1 which requires running Rust compiler compiled on the architecture itself and testing stuff on with it. Only full desktop systems will be Tier 1, because those are the systems that you can run Rustc and all the nice desktop environments.

However most of the embedded world uses ARM chips and they are Tier 2 like thumbv6m and thumbv7em (there are still odd ones like 8051 or AVR or m68k, many of them lack a good C++ compiler already). They are guaranteed to be built and at the release time the tests still run for them.

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

#217

  // The Old Way (don't do this)
  char* include_pattern = NULL;
  if (optarg) {
      include_pattern = strdup(optarg);
  }
  // ...200 lines later...
  if (some_error) {
      if (include_pattern) free(include_pattern); // Did I free it? Did I??
      return 1;
Nope!

  // ...200 lines later...
  // common return block

  out:
  free(include_pattern);  // free(NULL) allowed since before 1989 ANSI C
  return result;

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

#218

Earlier quoted context omitted.

MSVC is also made out of a dozen javascript processes which makes typing text need a beefy computer.

MSVC is a C++ compiler toolchain and it does not contain any JavaScript. You're thinking of VSCode, probably, but your comment was an off-topic rant either way.

Microsoft visual studio the IDE (not vs code the electron program) has lots of javascript processes running in the background doing all sorts of things.

Also my comment was a single sentence with a single fact so it can't be a rant.

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

#219

Earlier quoted context omitted.

I think that's an orthogonal issue. It's not that C++'s shared pointer is not a zero cost abstraction (it's as much a zero cost abstraction as in Rust), but that it only provides one type of a shared pointer. But I suppose we're wasting time on useless nitpicking. So, fair enough.

I think they’re one and the same: C++ doesn’t have program-level thread safety by construction, so primitives like shared pointers need to be defensive by default instead of letting the user pick the right properties for their use case. Edit: in other words C++ could provide an equivalent of Rc, but we’d see no end of people complaining when they shoot themselves in the foot with it. (This is what “zero cost abstract…

> C++ doesn’t have program-level thread safety by construction

It does. It’s called a process.

Everyone chose convenience and micro-benchmarks by choosing threads instead.

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

#220
This won't play along with setjmp/longjmp exception handling schemes, unfortunately, without a lot of extra effort.

You can do cleanup handling that integrates with your exception handling library by using pairs of macros inspired by the POSIX pthread_cleanup_push stuff.

  #define cleanup_push(fn, type, ptr, init) { \
    cleanup_node_t node; \
    type ptr = init; do cleanup_push_api(&node, fn, ptr) while (0)

  #define cleanup_pop(ptr) cleanup_pop_api(ptr) \
  }
cleanup_push_api places a cleanup node into the exception stack. This is allocated on the stack: the node object. If an exception goes off, that node will be seen by the exception handling which will call fn(ptr).

The cleanup_pop_api call removes the top node, doing a sanity check that the ptr in the node is the same as ptr. It calls fn(ptr).

The fact that cleanup_push leaves an open curly brace closed by cleanup_pop catches some balancing errors at compile time.

The POSIX pthread_cleanup_pop has an extra boolean parameter indicating whether to do the cleanup call or not. That's sometimes useful when the cleanup is only something done in the case of an abort. E.g. suppose tha the "cleanup" routine is rollback_database_transaction. We don't want that in the happy case; in the happy case we call commit_database_transaction.

Post reply on HN