[ot][coding-therapy?] Moronism And The Thorough Code Review

Undescribed Horrific Abuse, One Victim & Survivor of Many gmkarl at gmail.com
Thu Oct 27 16:07:32 PDT 2022


It was while revisiting some static initialization order issues with
the spdlog log library that I finally noticed I could think of these
things this way.

It's somewhat sad that I'm engaging spdlog, which I mostly value
because of its use in the BrainFlow library, a small MIT-licensed
brain signal interface by a lone developer in Russia. I wouldn't be
using BrainFlow if I could get myself set up with OpenViBE, a much
larger LGPL-licensed brain signal environment from France, but with
OpenViBE I get the chest contractions and amnesia and such more
strongly, and then with the amnesia I forget it exists, and stumble on
BrainFlow, and the rest is timelines.

Anyway, BrainFlow inherits design flaws from its dependency on spdlog,
which has static destruction order issues in its implementation,
resulting in patterns of using static objects but having to jump
through hoops to output log information in their destructors.

The static destructor issues in spdlog are multi-fold, moreso for me
because the C++ specification has had many new revisions since I
stopped reading written text. Some of them relate to quirks of DLL
unloading on different versions of Windows.

I first made myself visible to spdlog on 2021-02-20, looking for
details regarding the DLL unloading concern. Things happened and were
raised by different people, time has passed. A new issue was opened
for a more core part of things. Not much action.

On 2022-08-16, tfiner made a comment more experienced than others, on
the new issue thread, at
https://github.com/gabime/spdlog/issues/1738#issuecomment-782632346 .
tfiner basically proposes to redesign the parts of the library
involved, rather than to address the issues in the current API. tfiner
speaks in line with my own original concern when saying "It is an
unusual library that can't be called from a static object's destructor
deterministically and safely."

Today, I had some casual interest in resolving this, not knowing of
the new developments.

Usually, I would go through all the options, pick the best one, bang
it out, and contribute it. And I'm still used to assuming I can do
this! Nowadays _all_ the options is more like ... "uhhh how many
intergalactic amnesia bubbles do I have to send autonomous time
traveling robots from in order to bring these things together, and
what patterns do the autonomous time traveling robots need to collect
before they unite?" which may make no sense to you but is hilarious
and sympathetic for me when I write it.

Another thing I notice is that it is again incredibly hard for me to
consider, design, and write code, and this difficulty is in some new
ways that I'm not expecting. When I experience severe coding trouble,
I remember a number of years ago, when coding was even harder for me
(although in different ways) and then how I returned to coding in some
years between. This memory is always inspiring for me, although I'm
not quite certain of how much to rely on it.

Big large questions with the spdlog situation might be:
- What is the best solution or solutions?
- What is needed to implement it or them?
- What are the details of the problem and its systems to find obscure
options and obscure concerns?

My usual approach would be to consider every possible option, and then
pick among them. When it can take navigating convulsions to explore
exotic, low-return options, part of me can get kind of angry at other
parts of me, to spend my time that way. I'm never quite sure. But for
thoroughness, I expect that continuing to try can make things easier.
It can take a lot of intentional and ritualised repetition to get to
that point.

Areas I might need more information on might include:
- Revisions of Windows that have DLL unloading quirks and the specific
details of those quirks
- Possible avenues present in whatever the latest C++ specification is
that the project supports
- The static construction and destruction rules specified by the
standard, and separately the rules adhered to by every mainstream
compiler the project supports
- The preferences and norms of the users and developers of the
project, and of experienced C++ programmers in general

Ideally, there is a solution that retains backwards compatibility, but
if the project is conducive to an upgrade that solves all the problems
at once and deters future ones, then simply implementing an approach
like tfiner's makes sense. But one can never know for sure without a
thorough review. There's always a little nook of options that can
yield a lot of fruit. Every hacker knows this.


More information about the cypherpunks mailing list