Mankaninen

extrano84 already found some errors but also 0 will fail and if x is int (instead of unsigned int) all negative numbers will also fail (but so will the original s-macke obfuscation as well).

Of course you should do the right thing, but if you want to break the private of C++ it is much easier to "#define private public" before including the header file.

I'm on Linux Mint (21.2) and get the same error. Probably macOS only. A quick reading in readthedocs confirms it is macOS only, no Linux, no Windows.

The article is not correct on salaries being public: What is public are your tax reports and those are done a year later. To my knowledge you cannot see all details either, only totals that the tax is based on. Thus I think your statement is wrong or at least it is not related to the public databases mentioned in the article.

A modern car has >100 ECUs, blink is distributed to a few ECUs, think: front body, rear body, left door, right door plus instrument cluster and maybe a trailer control ECU. It does not look premium if they do not blink in phase so you send CAN command for blinking. (A separate cable introduce cost, weight and faults due to corrosion that are tricky to diagnose, in total you want to avoid that.) If something disturb CAN or an ECU reboots you would get the described behavior. But it is not obvious (at least not to me) that it must be a software error - could easily be hardware designed with too small margins. (I have not worked with this issue at Volvo and do not know the actual cause of the problem.)

ECU is abbreviation for Electronic Control Unit in automotive. (And a modern car may actually have multiple ECUs controlling the engine(s), especially if it is a hybrid=HEV, plugin HEV=PHEV or battery electric vehicle=BEV.)

There is one more problem with encrypted elections not yet listed here; the vote is secret for now but 5, 10 or 20 years later it will be easy to break.

This might mostly be a problem for those then powerful, if someone find out that they voted "wrong" long time ago, our trust in them will be reduced. Yet a way to do negative campaigning.

While f/64 sounds like a small aperture, it can be worth remembering that it was on large format cameras. A small sensor like on iPhone 6 is wide open corresponding to depth matching f/113! (iPhone6 is f/2.2, crop is 7.21, 8"x10" camera is crop 0.14. 7.21/0.14*2.2 = f/113)

I agree with this thinking. It is also possible that competitors to multi-billion contract being awarded to AWS by DoD wants an argument to distributing the contract among many cloud suppliers to reduce risk. Bloomberg has worked with this story for a year - is that a man-year or a calendar year? If the latter, both trade-war and the DoD contract are less probable.

I don't know the percentage B2B vs consumer-focused startups in EU or US so giving a few examples makes no real sense but Spotify, iZettle, Skype and Pirate bay are all of swedish origin. And business taxes in Sweden are among the low ones in OECD. Salary (after tax) is lower than in US but schools and health care is free so compared to US the living standard is not that bad, i.e. assuming the original poster assumption is correct, I don't think taxes is the explanation.

I think more CPU performance is attractive if you edit photos or movies - something that is typical for a home computer. The reason AMD provides CPU performance through a high core count is because it is power efficient, otherwise a single-core is easier to program.

With respect to the bmp example: 1. Removing the bmp_get implies that the application needs to implement a shadow image if it needs to check the color o a certain pixel. Or even worse, take a direct peek in its void memory area. 2. void pointers instead of bmp_pointers makes it easier to create a mess, the compiler will not tell you that you called the bmp library with a pointer to a jpg memory area. 3. Not doing range checking in the library - but imposing that burden on the caller - is a bad practice. If the caller does the same - expects his caller to do the checking - we end up with a sequrity risk.

Trying to minimize the library by pushing work to the application is wrong every time you expect the library to be used more than once. Despite these objections, I like libraries that are free of IO and mallocs!