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

71–80 of 277 posts

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

#71

Post by woodruffw »

saurik wrote: post #56
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.

To lift things up a level: I think a language’s abstractions have failed if we even need to have a conversation around what “cross platform” really means :-)

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

#72

Post by Snarwin »

Phil_Latio wrote: post #63
jerf wrote: 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 In a system programming language?

There's plenty of application-level C and C++ code out there that isn't performance-critical, and would benefit from the safety a garbage collector provides.

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

#73

Post by pjmlp »

HexDecOctBin wrote: post #30
nmeofthestate wrote: post #17

Earlier quoted context omitted.

Bit of a random question on an article about C.

The article clearly states that the code only works on GCC and Clang, which leaves MSVC. Not sure how the question was random.

There are other C compilers.

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

#74

Post by kouteiheika »

cogman10 wrote: post #45
kouteiheika wrote: post #40

Earlier quoted context omitted.

> the shared pointer implementation uses a POSIX mutex [...] C++’s shared pointer has the same problem It doesn't. C++'s shared pointers use atomics, just like Rust's Arc does. There's no good reason (unless you have some very exotic requirements, into which I won't get into here) to implement shared pointers with mutexes. The implementation in the blog post here is just suboptimal. (But it's true that C++ doesn't ha…

> very exotic requirements I'd be interested to know what you are thinking. The primary exotic thing I can imagine is an architecture lacking the ability to do atomic operations. But even in that case, C11 has atomic operations [1] built in. So worst case, the C library for the target architecture would likely boil down to mutex operations. [1] https://en.cppreference.com/w/c/atomic.html

Well, basically, yeah, if your platform lacks support for atomics, or if you'd need some extra functionality around the shared pointer like e.g. logging the shared pointer refcounts while enforcing consistent ordering of logs (which can be useful if you're unfortunate enough to have to debug a race condition where you need to pay attention to refcounts, assuming the extra mutex won't make your heisenbug disappear), or synchronizing something else along with the refcount (basically a "fat", custom shared pointer that does more than just shared-pointering).

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

#75

Post by palata »

762236 wrote: post #59
palata wrote: post #39

Earlier quoted context omitted.

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

Have you ever measured the performance impact of JNI? :-)

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

#76

Post by [deleted] »

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…

[deleted]

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

#77

Post by sesm »

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?

IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency.

A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

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

#78

Post by sesm »

krapht wrote: post #2

C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.

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

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

#79

Post by capitol_ »

keyle wrote: post #5

I don't understand this passion for turning C into what it's not... Just don't use C for sending astronauts in space. Simple. C wasn't designed to be safe, it was designed so you don't have to write in assembly. Just a quick look through this and it just shows one thing: someone else's walled garden of hell.

I agree, if people just had refrained from building things in c/c++ that operated on data from across a security boundary we wouldn't be in this mess.

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

#80

Post by dboon »

krapht wrote: post #2

C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.

No name mangling by default, far simpler toolchain, no dependence on libstdc++, compiles faster, usable with TCC/chibicc (i.e. much more amenable to custom tooling, be it at the level of a lexer, parser, or full compiler).

C’s simplicity can be frustrating, but it’s an extremely hackable language thanks to that simplicity. Once you opt in to C++, even nominally, you lose that.

Post reply on HN