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

191–200 of 277 posts

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

#191

Post by loeg »

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…

Tecnhically the mutex refcounting example is shown as an example of the before the header the author is talking about. We don't know what they've chosen to implement shared_ptr with.

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

#192

Post by loeg »

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.

Microsoft doesn't implement Annex K, either. They ship an non-conforming implementation. Literally no one cares about the "standardized" Annex K version.

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

#193

Post by loeg »

throwaway889900 wrote: post #121

Does the StringView/Span implementation here seem lacking? If the underlying data goes away, wouldn't the pointer now point to an invalid freed location, because it doesn't track the underlying data in any way?

That's what std::string_view and std::span are, though. They're views / borrows over the underlying data, minus the kind of protections something like Rust has about lifetimes of the underlying data vs the borrow.

The benefit of these types is that they're a pair of pointer+size, instead of just a bare pointer without a known size.

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

#194

Post by lpribis »

addaon wrote: post #143
colonwqbang wrote: post #109

Earlier quoted context omitted.

Does there exist any platform which has multithreading but not atomics? Such a platform would be quite impractical as you can't really implement locks or any other threading primitive without atomics.

> Does there exist any platform which has multithreading but not atomics? Yes. Also, almost every platform I know that supports multi threading and atomics doesn’t support atomics between /all/ possible masters. Consider a microcontroller with, say, two Arm cores (multithreaded, atomic-supporting) and a DMA engine.

Yes but "atomic" operations with the DMA engine are accomplished through interrupts (atomic) or memory mapped IO configuration (atomic).

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

#195

Post by loeg »

binaryturtle wrote: post #168
kerkeslager wrote: post #97

I feel like there might be some value in this header file for some projects, but this is exactly the wrong use case. > In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined. No, no, no. Command line options that will exist the entire lifetime of the program are the quintessen…

There are (older) OSes where this is NOT the case. Leaving things un-freed would leak memory after the application has terminated.

Sure, like prior to the invention of virtual memory. But those days are in the distant past.

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

#196

Post by loeg »

kev009 wrote: post #136
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…

C11 has a mutex API (threads.h), so why would it rely on POSIX? Are you sure it's not an runtime detail on one platform? https://devblogs.microsoft.com/cppblog/c11-threads-in-visual...

The article has an excerpt using posix mutexes specifically. But you're right that C11 code can just portably use standard mutexes.

  // The old way of manual reference counting
  typedef struct {
      MatchStore* store;
      int ref_count;
      pthread_mutex_t mutex;
  } SharedStore;

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

#197

Post by jesse__ »

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

lol .. reality disagrees with you.

https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf#:~:te...

On page 3 they broadly conclude that if you use FIVE TIMES as much memory as your program would if managed manually, you get a 9% performance hit. If you only use DOUBLE, you get as much as a 70% hit.

Further on, there are comprehensive details on the tradeoffs between style of GC vs memory consumption vs performance.

---

Moving a value from DRAM into a CPU register is an expensive operation, both in terms of latency, and power consumption. Much of the code out in the "real world" is now written in garbage collected languages. Our datacenters are extremely power hungry (as much as 2% of total power in the US is consumed by datacenters), and becoming more so every day. The conclusion here is that garbage collection is fucking expensive, in real-world terms, and we need to stop perpetuating the idea that it's not.

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

#198

Post by cryptonector »

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…

Meh, it could easily use atomics instead, no lock needed.

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

#199

Post by accelbred »

eddd-ddde wrote: post #160
accelbred wrote: post #126

Earlier quoted context omitted.

Unfortunately, for C++, thats not true. At least with glibc and libstdc++, if you do not link with pthreads, then shared pointers are not thread-safe. At runtime it will do a symbol lookup for a pthreads symbol, and based off the result, the shared pointer code will either take the atomic or non-atomic path. I'd much rather it didnt try to be zero-cost and it always used atomics...

Why use atomics if you don't need them? There really should just be two different shared pointer types.

I wouldn't mind two types. I mind shared pointer not using atomics if I statically link pthreads and dlload a shared lib with them, or if Im doing clone3 stuff. Ive had multiple situations in which the detection method would turn off atomic use when it actually needs to be atomic.

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

#200

Post by jesse__ »

wavemode wrote: post #113
sesm wrote: post #77

Earlier quoted context omitted.

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.

Java (w/ the JIT warmed up) could possibly be faster than C++, if the C++ program were to allocate every single value on the heap. But you're never going to encounter a C++ program that does that, since it makes no sense.

Entertaining anecdote:

I once worked on a python program that was transpiled to C++, and literally every variable was heap allocated (because that's what python does). It was still on the order of 200x faster than python IIRC.

Post reply on HN