memcpy() and strcpy() are not found in proper C++ programs (there is no need for them).

Anyway, memcpy is not the cause for buffer overruns. Buffer overruns appear when two pieces of code get confused about what is the actual size of the buffer. In C++, the actual size is stored right there inside the buffer object (e.g. std::vector or std::string), so the probability of confusion is greatly reduced.

strcpy() is vulnerable because it relies on the buffer size stored somewhere else in addition to the buffer management (i.e. malloc()), and these two locations may get inconsistent and cause confusion and bugs. Luckily, there is about zero reason to use strcpy() in C++.

Of course one can compile what is basically C code by a C++ compiler, but this does not mean one could not do better in C++, or that C++ is somehow tainted by allowing C code. One can write buggy code in any language, writing buggy C code in C++ is just one easy way to do that.

I believe you have mixed up C++ with some other language. C++ does not have any such buffer overrun issues (unless you treat it as "C with classes", of course).

Microsoft has not been able to provide useful error messages for the last 30 years, why should it be any different with QR codes?

Unfortunately, this will have no effect on Putin. He might even win some more support as a clear victim of the evil western propaganda.

Indeed, there is no need for that. You need to sync only if something must get visible to another thread.

As written, this statement seems indeed either insane or tautological. I am not surprised SO people were baffled.

A semaphore is a totally different thing than an ordinary user-defined class object.

This article is now blocked as well!

I know the sentiment. The only thing worse than open-source software from academia is closed-source software from academia. We ended up putting it in a separate background process so when it crashes we can try to run it again a couple of times.

Making some program open-source does not magically increase its quality, and being in academia does not magically turn professional scholars into professional programmers. Nothing new here.

Yes, the do. For example, in Switzerland it is estimated that health care errors cause 1,000-plus deaths a year.

In the article there are a lot of comparisons to doctors. Like, how you can become a doctor by spending 7 years in a medical school, etc, whereas in programming you do not have a clear path.

To my mind, this only proves that nobody really questions the qualification of the doctor. The patients are (or considered to be) not qualified to do that, so unless you are very bad, you can carry out a successful doctor career without really mastering the skills. I am sure in no way can all people become good doctors if they spend 7 years in medical schools, and the same applies to programmers. The only difference is that for a computer program it is much easier to see if it works and who is responsible when it doesn't.

Yes, it's 2015 and so it would be appropriate to realize that C and C++ are two totally different languages (where one of those is just capable to seamlessly compile most of the code written for the other).

So, who won?

Well, in this case they have clearly failed as the case is obviously very important (can overturn the whole concept of SDK-s) and is pretty clear-cut. So it appears the government thinks it's in its interest to sink the whole digital revolution. Well, considering that a moderate AI might perform better in their jobs, they might be right...

Good code has documentation for knowing what it should do, and has unit tests to verify that it actually does that. If there are any problems good code can be modified to meet the (possibly changed) requirements better, while unit tests ensure the modifications do not make the code worse. Code which cannot be modified is not good code. It's that simple.