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

31–40 of 277 posts

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

#31

Post by HexDecOctBin »

pjmlp wrote: post #20
HexDecOctBin wrote: post #8

Any hopes that MSVC will add C23 support before 2040?

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.

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

#32

Post by khaledh »

The problem with macro-laden C is that your code becomes foreign and opaque to others. You're building a new mini-language layer on top of the base language that only your codebase uses. This has been my experience with many large C projects: I see tons of macros used all over the place and I have no idea what they do unless I hunt down and understand each one of them.

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

#33

Post by quotemstr »

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

FWIW, it's heavily used inside Microsoft and is actually pretty nice when combined with all the static analysis tools that are mandatory parts of the dev cycle.

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

#34

Post by kstrauser »

mightyham wrote: post #24
kstrauser wrote: post #16

Earlier quoted context omitted.

God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.

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 easier upgrade alternatives!

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

#35

Post by 762236 »

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?

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

#36

Post by woodruffw »

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

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

#37

Post by pjmlp »

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.

People keep forgetting Microsoft is one of the biggest publishers in the market, given the number of owned studios.

The box under the TV is a tiny part of the picture that makes Microsoft Games Studios and related subsidiaries.

https://en.wikipedia.org/wiki/List_of_Microsoft_Gaming_studi...

If Microsoft really gets pissed due to SteamOS and Proton, there are quite a few titles Valve will be missing on.

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

#38

Post by woodruffw »

hanstospace wrote: post #25

I checked Fil-C out and it looks great. How is this different from Fil-C? Apart from the obvious LLVM stuff

Fil-C essentially lifts C onto a managed, garbage-collected runtime. This is a small header that adds some C++ features to C.

(These features are still essentially unsafe: the unique pointer implementation still permits UAF, for example, because nothing prevents another thread from holding the pointer and failing to observe that it has been freed.)

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

#39

Post by palata »

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?

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

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

#40

Post by kouteiheika »

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 have Rust's equivalent of Rc, which means that if you just need a reference counted pointer then using std::shared_ptr is not a zero cost abstraction.)

Post reply on HN