Another pet peeve of me is that the global namespace is littered with these utility functions that should be easily composable or maybe be methods on the objects themselves - and looks like PHP 8.4 adds four more `array_*` functions. For comparison, Python's builtin namespace has a total of 71 functions and a couple of exception classes. PHP's builtin namespace has more functions for dealing with arrays and now 58 of those are prefixed with `array_`.

C89 says that "The value of a pointer that refers to freed space is indeterminate." and that behavior is undefined "upon use ... of indeterminately-valued objects", hence a compiled program can e.g. behave as if `new_pointer == old_pointer` even though the object was relocated in memory.

First of all the name My is (Finland-)Swedish, the Finnish name of the character is Pikku Myy.

The Finnish name registry contains only ~2 mentions before the publication of the hugely popular first Moomin book (and none for Myy) so this girls' name and hence the name in the MySQL really comes from the Moomin stories.

And finally, the name of Little My is a play on the Greek small letter mu, i.e. μ, and you'd be closer to the real idea and original pronunciation if you thought of it as MuSQL (μSQL) instead ;)

       const  Functions marked with const as an MT-Safety issue non-
              atomically modify internal objects that are better
              regarded as constant, because a substantial portion of the
              GNU C Library accesses them without synchronization.
              Unlike race, which causes both readers and writers of
              internal objects to be regarded as MT-Unsafe, this mark is
              applied to writers only.  Writers remain MT-Unsafe to
              call, but the then-mandatory constness of objects they
              modify enables readers to be regarded as MT-Safe (as long
              as no other reasons for them to be unsafe remain), since
              the lack of synchronization is not a problem when the
              objects are effectively constant.

              The identifier that follows the const mark will appear by
              itself as a safety note in readers.  Programs that wish to
              work around this safety issue, so as to call writers, may
              use a non-recursive read-write lock associated with the
              identifier, and guard all calls to functions marked with
              const followed by the identifier with a write lock, and
              all calls to functions marked with the identifier by
              itself with a read lock.

       env    Functions marked with env as an MT-Safety issue access the
              environment with getenv(3) or similar, without any guards
              to ensure safety in the presence of concurrent
              modifications.

              We do not mark these functions as MT-Unsafe, however,
              because functions that modify the environment are all
              marked with const:env and regarded as unsafe.  Being
              unsafe, the latter are not to be called when multiple
              threads are running or asynchronous signals are enabled,
              and so the environment can be considered effectively
              constant in these contexts, which makes the former safe.