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

41–50 of 277 posts

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

#41

Post by miroljub »

brabel wrote: post #11
miroljub wrote: post #3

Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work. Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?

It would be a lot more constructive if you reported a bunch of corner cases where this doesn't work rather than just dismissing this as a toy.

No, I don't dismiss anything.

It's just, I'd rather play with my own toys instead of using someone else's toy. Especially since I don't think it would ever grow up to be something more than a toy.

For serious work, I'd use some widely used, well-maintained, and battle-tested library instead of my or someone else's toy.

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

#42

Post by woodruffw »

kouteiheika wrote: post #40
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 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…

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.

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

#43

Post by spacedcowboy »

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

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

#44

Post by cachius »

HexDecOctBin wrote: post #31
pjmlp wrote: post #20

Earlier quoted context omitted.

Given how C was seen in the past, before there was a change of heart to add C11/C17, minus atomics and aligned memory allocators (still between experimental or not going to happen), https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual... https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp... And the new guidelines regarding the use of un…

Well, with the death of Xbox and release of raddebugger, maybe supporting VS/MSVC just isn't that important anymore. Good riddance.

https://github.com/EpicGamesExt/raddebugger

At first I read Radeberger, a German beer brand.

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

#45

Post by cogman10 »

kouteiheika wrote: post #40
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 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

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

#46

Post by kouteiheika »

woodruffw wrote: post #42
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…

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.

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

#47

Post by mightyham »

kstrauser wrote: post #34
mightyham wrote: post #24

Earlier quoted context omitted.

Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.

I meant the collective bulk of legacy C code running the world that we can’t just rewrite in Rust in a finite and reasonable amount of time (however much I’d be all on board with that if we could). There are a million internal C apps that have to be tended and maintained, and I’m glad to see people giving those devs options. Yeah, I wish we (collectively) could just switch to something else. Until then, yay for easie…

I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including the adoption of something like safe_c.h (I can hardly fathom the insanity of trying to migrate a million LOC+ of C to that library in a single go). I'm arguing that engineering effort would be better spent refactoring and rewriting the application in a fully safe language one small piece at a time.

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

#48

Post by _vqpz »

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.

>Nothing is stopping you from writing c-like c++ if that's what you like style wise.

You'll just have to get used to the C++ community screaming at you that it's the wrong way to write C++ and that you should just use Go or Zig instead

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

#49

Post by 1718627440 »

Borg3 wrote: post #7
miroljub wrote: post #3

Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work. Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?

Yeah, kids like to waste time to make C more safe or bring C++ features. If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases. If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return. Temporary buffers? if they arent big, dont be afraid to use static char buf[64]; No…

> static char buf[64];

In a function? That makes the function not-threadsafe and the function itself stateful. There are places, where you want this, but I would refrain from doing that in the general case.

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

#50

Post by kstrauser »

mightyham wrote: post #47
kstrauser wrote: post #34

Earlier quoted context omitted.

I meant the collective bulk of legacy C code running the world that we can’t just rewrite in Rust in a finite and reasonable amount of time (however much I’d be all on board with that if we could). There are a million internal C apps that have to be tended and maintained, and I’m glad to see people giving those devs options. Yeah, I wish we (collectively) could just switch to something else. Until then, yay for easie…

I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including the adoption of something like safe_c.h (I can hardly fathom the insanity of trying to migrate a million LOC+ of C to that library in a single go). I'm arguing that engineering effort would be better spent refactoring and rewriting the application in a fully…

I’m not sure I agree with that, especially if there were easy wins that could make the world less fragile with a much smaller intermediate effort, eg with something like FilC.

I wholeheartedly agree that a future of not-C is a much better long term goal than one of improved-C.

Post reply on HN