Chris Wellons

i think it's pretty common for a specialized reimplementation of a standard library type or function to outperform it by an order of magnitude or so in some particular case. chris wellons gave an excellent example of this with hashing in golang in https://nullprogram.com/blog/2023/06/26/

commonly (as in wellons's post about the two-sum problem) there's a variation on the standard algorithm that can help significantly, but which the standard library function doesn't have an option for

also i think the cost of reimplementing simple 'algorithms from the book' like insertion sort or even quicksort is pretty low; as you saw in my comment above, insertion sort is six lines of code and only moderately bug-prone. we aren't talking about fibonacci heaps or red-black trees or fm-indexes or rader's algorithm or something. the cost is low enough that it's easy to justify in a lot of cases

I misunderstood the question then, since I thought it was about learning about the newer language features.

C coding standards differ quite a lot, and unfortunately I can't point out any software that has standards developed for safety.

As to still try and be helpful: I've enjoyed reading nullprograms blog[0] where he looks into interesting ways to make C more useable (although he tends to replace the entire standard library for reasons highlighted here[1])

There is some must avoid functions (mostly string functions) and a good list of them has been compiled in the git project repository[2].

I've tried looking up the misra C guidelines but they were hard to find or (if I remember correctly) had to be paid for or something like that

[0] https://nullprogram.com [1] https://nullprogram.com/blog/2023/02/11/ [2] https://github.com/git/git/blob/master/banned.h

Julia Evans' blog is one of my favorites! It was a big inspiration for starting my own blog (https://andythemoron.com). I also love High Scalability and Dan Luu's blog which have been mentioned in other comments.

I "follow" several which are mostly defunct, but in terms of blogs that still feature active updates:

Evan Klitze's blog: lots of topics around Linux, C++, etc. https://eklitzke.org/

Sutter's Mill: lots of "state of the world" for C++, but also context, history, etc. https://herbsutter.com/

IT Hare: C++, game programming http://ithare.com/

The Erlangelist: Erlang/Elixir http://theerlangelist.com/

null program: lots of miscellaneous topics http://nullprogram.com/

Fluent C++: the name speaks for itself http://www.fluentcpp.com/

Another Programmer's Blog: Linux, C, C++, C#, MSSQL https://www.stev.org/

I've looked around more, and I should probably write a better/fuller comparison of other things with what I experiment with. I think the more unusual thing, and useful observation, is that multiplying with the result of a varying bitrotation (what I thought of as "chaotic waveshaping") can be enough to make it sound like white noise (though more is needed to make all bits decently random). It makes it possible to use a multiplication less.

SplitMix64 uses another multiplication and only fixed bitshifts, and is 64-bit. I've found more about the standard form of its core - a permuting hash function with two multiplications and three xor-right-shifts. There are also 32-bit functions of that type, where the best seem to be listed in this article on the topic: https://nullprogram.com/blog/2018/07/31/

Yeah, so you are probably right. The custom definition is something that grew out of my response to the following two posts:

A general review of the stdlib
https://nullprogram.com/blog/2023/02/11/

A review of scanf
https://sekrit.de/webdocs/c/beginners-guide-away-from-scanf.html

Originally I implemented `getLine` (terrible name!) as a way to get multiple lines of input from stdin in a relatively safe way. The implementation borrows almost all of its ideas from the `sekret.de` post. Because I knew the implementation and it was close to hand on my machine, I used it for this version and just swapped out `stdin` for just any old file.

Edit: here's the implementation for reference, https://github.com/adammccartney/algorithms/blob/master/libs/adio/adio.c

Please DON'T use the threads. As of 2018 it has many data races (https://nullprogram.com/blog/2018/05/31/), and resultant bugs will be a nightmare to track down.

The Emacs community has always got by through finding other ways to ensure responsiveness. It's true that each individual user shouldn't have to spend that much time on configuration (Doom Emacs and such distros help here), but still: people who find it slow must have misconfigured something, and on profiling, they'll find at most 1 or 2 features of their config that's eating all the CPU cycles. These won't actually be hard to fix, for a programmer, and threads wouldn't have helped matters, and at best only have hid the CPU-eater.