What does HackerNews think of klib?

A standalone and lightweight C library

Language: C

#25 in C
#3 in Library
Smart pointers in C, wow, who would imagine? Although I must say, I'll probably never use this in a project because:

- Using C for anything but systems programming is either malevolence or for fun, there's no pratical reason for it. In this case you probably don't want to have external dependencies only to have data structures.

- Having dependencies in C is an absolute pain in the ass unless it's a single header file (such as sqlite). It also makes it much harder to make the codebase portable.

I might try it out though just for gigs and laughs.

Tangentially, I wonder why more C developers don't use self-contained dependencies such as GNULib [0], Klib [1], or APR [2] instead of reimplementing base primitives. It's so common for C projects to reimplement every single thing from scratch. "If you want to make a pie from scratch, you must first invent the universe" kind of thing.

Managing packages is a pain, but reimplementing an efficient battle-tested hash table is even worse IMO. Would be happy to hear it from people who worked (professionally) with C about this.

[0]: https://www.gnu.org/software/gnulib/

[1]: https://github.com/attractivechaos/klib

[2]: https://apr.apache.org/

strcpy - is a standard library issue, not language one. Most C projects creates their own "string handling" routines.

It is pity there is no alternative "standard library" with safer data struct and operations.

There are some attempts, for example, relatively wildly known klib: https://github.com/attractivechaos/klib

I’m actually implementing that right now for my own use, as a pre-processor.

There is a much more advanced design and implementation at “A defer mechanism for C” (December 2020): https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...

For my own purposes, I think I can live without handling stack unwinding so I continue working on my pre-processor.

Since the pre-processor is not yet finished, there I use a vector¹ of {.pointer, .destructor} where I put objects after initialization, with one macro at the end of each managed scope that calls the destructors for that scope in reverse order, then another macro meant for the function exit points that calls all the destructors in that vector. This has been built many times before by other people of course, it’s just an exercise to see which difficulties arise.

¹ Vector, growable array: I did my own trivial type-generic growable array, with the classic {.capacity, .len, .items}, but again there are many previous implementations. The two I’ve found more interesting are:

- “C Template Library (CTL)”: https://github.com/glouw/ctl

- “Klib: a Generic Library in C”: https://github.com/attractivechaos/klib/

This is in fact a pretty common pattern in production code.

Here's an entire suite of type safe generic data structures in C: https://github.com/attractivechaos/klib

These kinds of macro hacks are pretty widespread, aren't they? To me, klib and its khash hash table is the most well-known implementation, see: https://github.com/attractivechaos/klib

And I've written similar things myself (hash table and vectors).

I recommend ksplit/ksplit_core from Heng Li’s excellent klib kstring.{h,c}[0]. It modifies the string in-place, adding null terminators, and provides a list of offsets into the string. This gives you the flexibility of accessing tokens by index without paying costs of copying or memory allocation.

[0] https://github.com/attractivechaos/klib