I don't think you understood my article since I agree with you about such 
pleas and professional competence. I'm not talking about safety beyond 
simple correctness. Anywhere you might use strcpy() (or strlcpy(), etc.) 
it makes more sense to use memcpy(). If you can't drop memcpy() in its 
place then you're not using strcpy() correctly. I've never seen a 
legitimate use case for strcpy() (or strlcpy(), etc.), and I'm speaking 
strictly from a perspective of correctness and efficiency — qualities I 
believe are more important than safety.

The point of the article is that anywhere you might use strlcpy() you 
should instead use memcpy() anyway. There are no advantages to using 
strlcpy() even if it is available.

Oh yeah, without a stable ABI there's little hope of using C++ across such 
boundaries. Since w64devkit statically links libstdc++ there are even a 
few gotchas since each side has its own copy of the standard library, 
including static variables, even if it's the exactly same library. For 
instance, modules have distinct std::cout and std::cin objects. I wondered 
if there was something more insidious, so I searched the libstdc++ sources 
and found an interesting case with std::atomic<T>::wait. Here's main.cc:

    #include <atomic>
    #include <thread>

    void sleep_then_set(std::atomic<int> &); // (from library.dll)

    int main()

Thanks, Vincent! That's what I get for retyping it on-the-fly rather than 
reading in the source via :read. Your patch has been merged.

Good question, Stefan. It's not a strong preference, but what tipped the 
balance:

1. While writing this program I was already thinking in terms of concrete 
values, considering if there were any subtle ways I (or the compiler) 
might exploit the specific ASCII values for dash and dot. Since conversion 
between hex and binary is trivial, just looking at 0x2e and 0x2d I can 
tell that they differ in their last two bits. Perhaps this could be used 
for a particularly efficient jump table? Could I transform the input to 
unlock some new optimization?

2. This program works exactly the same (i.e. it always processes UTF-8) 
regardless of locale. In C, the specific values of '-' and '.' depend on 
the implementation, so, for instance, a host using EBCDIC will have

> I'm curious if you have any tips on using patch and diff effectively to 
> manage source code, perhaps in the context of a small team (2-3 people)?

Quilt can serve as a practical example of what to do. It's a collection of 
scripts for patch-based workflows, predating Git. It essentially automates 
all the otherwise-manual work of running diff and patch yourself.

https://wiki.debian.org/UsingQuilt
http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf

Even in a world dominated by Git, Quilt still has its uses. Unlike Git, 
it's great for maintaining an independent, local patchset on top of an 
upstream code base. StGit attempts to be the best of both, being like Git 
where you need Git and like Quilt where you need Quilt, and studying it

> You sort of buried the lead :) waiting until the end to mention the very 
> cool Asteroids demo!

Heh, given your comment I've decided to move the video to the top of the 
article so that hopefully it more quickly grabs attention.

> This will be a nice dependency-less OpenGL and sound tutorial for me.

Note that it's OpenGL 1.1 since I wanted to keep it really simple. It's 
good enough for some things, like an Asteroids clone, but not everything. 
This is the last version of OpenGL directly supported by Windows, and so 
it's very easy to use. Later versions require accessing extensions, 
creating multiple OpenGL contexts, and using an OpenGL loader. I've worked 
all that out, too, in large part thanks to the OpenGL wiki, and I should

The workaround for MSYS2 in 475c111 interacts badly with a long-standing
bug in GNU Make where it avoids spawning a shell when it believes it can
handle a command itself as a sort of Bourne shell emulation. Since
"command" is typically implemented as a special shell built-in and not
an actual program, and GNU Make does not implement this built-in in its
Bourne shell emulation, GNU Make's shell function fails to invoke it
properly, resulting in an error:

    make: command: Command not found

One work-around is to set a custom shell that is not "/bin/sh" so that
GNU Make does not assume any particular shell semantics. For instance:

    make SHELL=dash
[message trimmed]

At least for C and C++, unless there are specific constraints — such as 
printing intermediate results not computed by FFT, or more likely, strict 
floating point error rounding (i.e. -fno-fast-math) — compilers are free 
to do this per the abstract machine. Only the DFT outputs are observable, 
not the inner workings.

IMHO, a compiler that transforms a generic DFT into FFT without having 
been programmed for that specific pattern is entering AI territory. I've 
noted in the past[1] that I've been a little freaked out at just how far 
optimizer reasoning can go. Both GCC and Clang can optimize non-tail 
recursive algorithms into iterative algorithms — without it being some 
specific algorithm — and your DFT example is really just a sophisticated 
version of this idea.

> --input-files *.jpg

This has no way to indicate where the arguments stop such that option 
processing can continue, so this option must go last. If it must go last, 
then these are really just positional arguments. If you do choose some 
sentinel to mark the end (perhaps "--") then there's the risk of an 
argument unintentionally matching as a sentinel, such as blog expansion. 
As you noted, stopping at the first option-like argument (a la argparse) 
is similarly unsound.

You mentioned repeated arguments, probably the most conventional way to 
supply multiple arguments for a particular option. For instance, there's 
ffmpeg's -i option. Though as you also noticed, this isn't friendly to 
globbing.