Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hwisnu.bearblog.dev

Post reply on HN
Print view View original

51–60 of 277 posts

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

#51

Post by woodruffw »

kouteiheika wrote: post #46
woodruffw wrote: post #42

Earlier quoted context omitted.

To be clear, the “same problem” is that it’s not a zero-cost abstraction, not that it uses the same specific suboptimal approach as this blog post.

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 abstraction” means: it doesn’t mean no cost, just that the abstraction’s cost is no greater than the semantically equivalent version written by the user. So both Arc and shared_ptr are zero-cost in a MT setting, but only Rust has a zero-cost abstraction in a single-threaded setting.)

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

#52

Post by jerf »

762236 wrote: post #35
cachius wrote: post #9

A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/

Why would I want to run a garbage collector and deal with it's performance penalties?

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, but it'd be helpful if those of you in that minority would speak as if you are in the small minority and not propagate the crazy idea that garbage collection comes with massive "performance penalties" unconditionally. They come with conditions, and rather tight conditions nowadays.

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

#53

Post by cassepipe »

fuhsnn wrote: post #23

> C23 gave us [[cleanup]] attributes C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE

It is surprisingly hard to find information about it, do you have any ? From what I can guess it's a new syntax but it's the feature itself is still an extension ?

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

#54

Post by woodruffw »

spacedcowboy wrote: post #43
woodruffw wrote: post #36

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…

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.

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

#55

Post by rurban »

debugnik wrote: post #15
rurban wrote: post #4

Just don't mix that up with the real safec.h header from safeclib: https://github.com/rurban/safeclib/tree/master/include

How can anyone be this interested in maintaining an annex k implementation when it's widely regarded as a design failure, specially the global constraint handler. There's a reason why most C toolchains don't support it. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

It's only regarded as design failure by the linux folks. Maybe because it came from Microsoft, NIH syndrome.

A global constraint handler is still by far better than dynamic env handlers, and most of the existing libc/POSIX design failures.

You can disable this global constraint handler btw.

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

#56

Post by saurik »

woodruffw wrote: post #36

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…

I'd think a POSIX mutex--a standard API that I not only could implement anywhere, but which has already been implemented all over the place--is way more "cross platform" than use of atomics.

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

#57

Post by hypeatei »

jerf wrote: post #52
762236 wrote: post #35

Earlier quoted context omitted.

Why would I want to run a garbage collector and deal with it's performance penalties?

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…

I think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree though: most programs aren't going to be brought to their knees over some GC sweeps every so often.

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

#59

Post by 762236 »

palata wrote: post #39
762236 wrote: post #35

Earlier quoted context omitted.

Why would I want to run a garbage collector and deal with it's performance penalties?

Easy: because in your specific use-case, it's worth trading some performance for the added safety.

If I'm in C, I'm using JNI to work around the garbage collector of Kava

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

#60

Post by 762236 »

jerf wrote: post #52
762236 wrote: post #35

Earlier quoted context omitted.

Why would I want to run a garbage collector and deal with it's performance penalties?

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…

For new projects, I just use Rust: there is zero reason to deal with a garbage collector today. If I'm in C, it's because I care about predictable performance, and why I'm not using Java for that particular project.
Post reply on HN