This article is a bit strange. It's referring to the thread stack size but acting as though it's the main stack size. It's true there's no portable C API for doing anything with the main stack size, but musl libc doesn't behave any differently than glibc here -- the main stack is allocated by the kernel. The thread stack size on musl is small, yes, but the only way to even end up in a thread involves using the pthread API. The pthread API exposes an API for configuring the stack size for a thread; it's called pthread_attr_setstacksize. You can find it here: https://pubs.opengroup.org/onlinepubs/9699919799/functions/p...

Granted, it is maddening that C does not offer any great ways to reason about what stack size is needed, but it is simply nonsense to imply (as people seem to be inferring here) that there's no way for an application to handle running into musl's stack size limits.

A given USB Type C cable can be a "USB 2.0" cable, which is only good for USB @ 480 Mbps and power, or a "USB 3.1" cable, which can handle USB @ 10 Gbps and power, as well as alternate data modes like DisplayPort or Thunderbolt. Additionally, it can be only good for 3 A, or it can have a chip in it to indicate it's good for more power (up to 5A).

The Apple-supplied cable is probably a USB 2.0 cable, with a chip indicating it can handle 5A.

The existence of two separate implementations of bubblesort (one for char, one for uint16_t), in and of it self, says everything that needs to be said about this. This was written by someone who refuses to use even the meager facilities C offers programmers, and doesn't know enough about them to even NIH things well. Moreover, he seems to like overtly complex, specialized code over simple, generic code.

(if the author of this library is reading this: qsort is a libc function that can sort an array of any type, in any way, and does so much more efficiently than bubblesort could ever dream, while not being very complex.)