libds VS chibicc

I may as well throw my hat into the ring: https://github.com/lelanthran/libds

I decided that I wanted to be able to simply drop a single .h file and a single .c file into any project without have to build a `libBlah.so` and link it to every project that needed (for example) a hashmap.

The practical result is that using the hashmap only requires me to copy the header and source files into the calling project.

It does build as a standalone library too, so you can link it if you want.

My primary reason for starting this is that I was pretty unsatisfied with all of the string libraries for C. When all I want to do is concatenate multiple strings together, I don't want to have to convert between `char ` and `struct stringtype ` everywhere.

The string functions are very useful as they all operate on the standard `char *` (nul-terminated) type.

That would be nice, then I wouldn't have to use non-standard stuff.

I made my own easy-to-incorporate-into-any-project library - https://github.com/lelanthran/libds - just copy the ds_*.h and ds_*.c into a project and you're good to go.

I'm not saying it will work for you, but it works for me.

> Is there a good string-manipulation C library?

You will have to define "good". My string library[1][2] is "good" for me because:

1. It's compatible with all the usual string functions (doesn't define a new type `string_t` or similar, uses existing `char `).

2. It does what I want: a) Works on multiple strings so repeated operations are easy, and b) Allocates as necessary so that the caller only has to free, and not calculate how much memory is needed beforehand.

The combination of the above means that many common* string operations that I want to do in my programs are both easy to do and easy to visually inspect for correctness in the caller.

Others will say that this is not good, because it still uses and exposes `char *`.

[1] https://github.com/lelanthran/libds/blob/master/src/ds_str.h

[2] Currently the only bug I know of is the quadratic runtime in many of the functions. I intend to fix this at some point.

As an example of an opaque pointer library, see https://github.com/lelanthran/libds/blob/v1.0.5/src/ds_ll.h - See line 7 for the typedef. - Lines 9, 10, 11 and 67, 68 and 69 for making it callable from C++.

If a --k&r mode was to be reliable, wouldn't it need to get specified first? Otherwise people would start relying on some edge case.

If speed is not a requirement for the --k&r mode, you could just take the tis-interpreter and note that if it runs without UB, it is still much faster than an actual computer was when k&r were active.

Would it even be possible to specify a variant of C that contains no UB (e.g. would define exactly what happens on unaligned access), but can compile practical existing C89 programs? I wonder if it could be written such that it could actually specify the behaviour consistently across the language intersection supported by both of e.g. GCC 2.95 and Chibicc[0].

Or maybe there are so many bugs in GCC 2.95 that it would simply be infeasible? How much time would it take to specify?

[0]: https://github.com/rui314/chibicc

I was on the Eclipse Foundation call a few days ago regarding this topic and they said there was a well-established 3-part test for this in the EU courts. But I don't think I managed to take a screenshot, sorry.

Here is a snippet from the EU Blue Guide linked the from the Eclipse blog post:

"Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context."

I would consider GCC or React to fit this definition, while a hobby project like https://github.com/rui314/chibicc not to fit it.

chibicc

chibicc: https://github.com/rui314/chibicc (A reasonably digestible C implementation)

When you say a fork of LLVM, am I correct in assuming that you specifically mean a fork of Clang? I don't see how the compiler backend would affect support for language extensions, regardless of whether it's an exception to that such as Tcc, Cproc, the MIR C jitter, lacc, 8cc, 9cc, and chibicc. Most of those are not for production, excluding Cproc and Tcc (at least according to Suckless or Oasis).