I don't think so. They are deliberately ignoring the side of the coin they don't like (a non ethno-state based on freedom and equality who has had a positive role in the history of mankind) because they are afraid that we don't take into account the side of the coin they care about, namely that all those rights and laws are mostly paper until some decide to make them more real.
If anything those perspectives need to be reunited rather than ignoring one for the other.
The history of humanity is filled with horrors and humans have done the worst to other humans but it is also true that nowhere in history has humanity been, on average, safer.
For that we have to thank all of those who believed in something better and made actual efforts to make a difference
It might be a you-problem then because that is not what they were about is about and yet you are the one grouping them together.
I am not saying categorization is bad, nor even that yours was unreasonable, but let's not forget the purpose of categories: Not having to think about difference, complexities
You would have done better to address and/or counter their points
Modern x86 CPUs have actual instructions for strcpy that work fairly well. There were several false starts along the way, but the performance is fine now.
They have instructions for memcpy/memmove (i.e. rep movs), not for strcpy.
They also have instructions for strlen (i.e. rep scasb), so you could implement strcpy with very few instructions by finding the length and then copying the string.
Executing first strlen, then validating the sizes and then copying with memcpy if possible is actually the recommended way for implementing a replacement for strcpy, inclusive in the parent article.
On modern Intel/AMD CPUs, "rep movs" is usually the optimal way to implement memcpy above some threshold of data size, e.g. on older AMD Zen 3 CPUs the threshold was 2 kB. I have not tested more recent CPUs to see if the threshold has diminished.
On the old AMD Zen 3 there was also a certain size range above 2 kB at sizes comparable with the L3 cache memory where their implementation interacted somehow badly with the cache and using "non-temporal" vector register transfers outperformed "rep movs". Despite that performance bug for certain string lengths, using "rep movs" for any size above 2 kB gave a good enough performance.
No, it's an instruction for memcpy. You still need to compute the string length first, which means touching every byte individually because you can't use SIMD due to alignment assumptions (or lack thereof) and the potential to touch uninitialized or unmapped memory (when the string crosses a page boundary).
The spec and some sanitizers use a scalar loop (because they need to avoid mistakenly detecting UB), but real world libc seem unlikely to use a scalar loop.
