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

61–70 of 277 posts

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

#61

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…

> use goto

My thoughts as well. The only thing I would be willing to use is the macro definition for __attribute__, but that is trivial. I use C, because I want manual memory handling, if I wouldn't want that I would use another language. And now I don't make copies when I want to have read access to some things, that is simply not at a problem. You simply pass non-owning pointers around.

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

#62

Post by kouteiheika »

woodruffw wrote: post #51
kouteiheika wrote: post #46

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…

I can't say I agree with this? If C++ had an Rc equivalent (or if you'd write one yourself) it would be just as zero cost as it is in Rust, both in a single-threaded setting and in a multithreaded-setting. "Zero cost abstraction" doesn't mean that it cannot be misused or that it doesn't have any cognitive overhead to use correctly, just that it matches whatever you'd write without the abstraction in place. Plenty of "zero cost" features in C++ still need to you pay attention to not accidentally blow you leg off.

Simply put, just as a `unique_ptr` (`Box`) is an entirely different abstraction than `shared_ptr` (`Arc`), an `Rc` is also an entirely different abstraction than `Arc`, and C++ simply happens to completely lack `Rc` (at least in the standard; Boost of course has one). But if it had one you could use it with exactly the same cost as in Rust, you'd just have to manually make sure to not use it across threads (which indeed is easier said than done, which is why it's not in the standard), exactly the same as if you'd manually maintain the reference count without the nice(er) abstraction. Hence "zero cost abstraction".

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

#63

Post by Phil_Latio »

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…

> Because about 99% of the time the garbage collect is a negligible portion of your runtime

In a system programming language?

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

#64

Post by 1718627440 »

rurban wrote: post #55
debugnik wrote: post #15

Earlier quoted context omitted.

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.

> Maybe because it came from Microsoft, NIH syndrome.

No it is because you still need to get the size calculation correct, so it doesn't actually have any benefit over the strn... family other than being different.

Also a memcpy that can fail at runtime, seems to be only complicating things. If anything it should fail at compile time.

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

#65

Post by archargelod »

You can get all of that and more with Nim[0].

Nim is a language that compiles to C. So it is similar in principle to the "safe_c.h". We get power and speed of C, but in a safe and convenient language.

> It's finally, but for C

Nim has `finally` and `defer` statement that runs code at the end of scope, even if you raise.

> memory that automatically cleans itself up

Nim has ARC[1]:

"ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII)"

> automated reference counting

See above

> a type-safe, auto-growing vector.

Nim has sequences that are dynamically sized, type and bounds safe

> zero-cost, non-owning views

Nim has openarray, that is also "just a pointer and a length", unfortunately it's usage is limited to parameters. But there is also an experimental view types feature[2]

> explicit, type-safe result

Nim has `Option[T]`[3] in standard library

> self-documenting contracts (requires and ensures)

Nim's assert returns message on raise: `assert(foo > 0, "Foo must be positive")`

> safe, bounds-checked operations

Nim has bounds-checking enabled by default (can be disabled)

> The UNLIKELY() macro tells the compiler which branches are cold, adding zero overhead in hot paths.

Nim has likely / unlikely template[4]

------------------------------------------------------------

[0] https://nim-lang.org

[1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

[2] https://nim-lang.org/docs/manual_experimental.html#view-type...

[3] https://nim-lang.org/docs/options.htm

[4] https://nim-lang.org/docs/system.html#likely.t%2Cbool

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

#66

Post by woodruffw »

kouteiheika wrote: post #62
woodruffw wrote: post #51

Earlier quoted context omitted.

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…

I can't say I agree with this? If C++ had an Rc equivalent (or if you'd write one yourself) it would be just as zero cost as it is in Rust, both in a single-threaded setting and in a multithreaded-setting. "Zero cost abstraction" doesn't mean that it cannot be misused or that it doesn't have any cognitive overhead to use correctly, just that it matches whatever you'd write without the abstraction in place. Plenty of…

Sorry, I realized I’m mixing two things in a confusing way: you’re right that C++ could easily have a standard zero-cost Rc equivalent; I’m saying that it can’t have a safe one. I think this is relevant given the weight OP gives to both performance and safety.

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

#67

Post by 1718627440 »

debugnik wrote: post #19
pkhuong wrote: post #6

Earlier quoted context omitted.

> Just don't use C for sending astronauts in space But do use C to control nuclear reactors https://list.cea.fr/en/page/frama-c/ It's a lot easier to catch errors of omission in C than it is to catch unintended implicit behavior in C++.

I consider code written in Frama-C as a verifiable C dialect, like SPARK is to Ada, rather than C proper. I find it funny how standard C is an undefined-behaviour minefield with few redeeming qualities, but it gets some of the best formal verification tools around.

The popular C compilers include a static analyzer and a runtime sanitizer. What features do you consider proper C? The C standard has always been about standardization of existing compilers, not about prescribing features.

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

#68

Post by pjmlp »

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?

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.

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

#69

Post by SAI_Peregrinus »

cassepipe wrote: post #53
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 ?

The `[[attribute]]` syntax is new, the builtin ones in C23 are `[[deprecated]]`, `[[fallthrough]]`, `[[maybe_unused]]`, `[[nodiscard]]`, `[[noreturn]]`, `[[reproducible]]`, and `[[unsequenced]]`.

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

#70

Post by naasking »

khaledh wrote: post #32

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.

I think this can be fine if the header provides a clean abstraction with well-defined behaviour in C, effectively an EDSL. For an extreme example, it starts looking like a high-level language:

https://www.libcello.org/

Post reply on HN