Why does the submitter suggest "zero" as the output for division by zero? How is that a better answer than 23?
Statistically, returning zero usually yields less horrible consequences than returning an arbitrary non-zero number.
If the result of the division is used in further calculations, e.g. in a product, a zero won't cause additional undefined behavior by signed integer overflows, etc.
Code which divides by zero is not "horribly" broken.
Depends on the code. If dividing by zero results in occasional audio glitches, it's not horribly broken. If dividing by zero results in the code occasionally killing people, it's horribly broken.
ARMs let you chose if you want a division by zero to result in an exception or in a result of zero (DIV_0_TRAP bit).
Of course, you need to get down to assembly to mess with this setting, since most programming languages specify a behavior in this case, or behave in an unspecificed way.
Then again, dividing by zero usually means that there's something wrong with your design.
In general, static code analysis can only improve the code quality marginally.
Finding a potential problem through static code analysis and fixing it before the release is usually much cheaper than finding the problem in the wild, tracking down the bug, fixing it, and patching everything that's out there.
... in the code at all costs to make it look pretty, and, hey, everyone's supposed to know the operator precedence rules. Which promptly come and bite them in the rear, see the "suspicious sum" paragraph.
I can see why one of the MISRA rules states that "limited dependence" should be placed on C operator precedence and expressions should be clarified (to the reader, not to the compiler) by using parentheses.
1) High-level radioactive waste is deadly to touch, hold, carry, etc., for hundreds of thousands of years.
No, it's not. The stuff that kills you if you stand next to it has half-lives below 50 years, which means that after one or two thousand years, there's hardly anything left of the original amount.
The isotopes with half-lives in the thousands of years don't emit enough radiation to give someone deadly radiation poisoning in a few minutes, but they will raise cancer rates if released into the environment at any point in the next couple of hundred thousand years.
Drinking beer and wine (unsupervised) is legal in most of Europe for kids aged 16 and above.
Actually, drinking is legal in Germany regardless of age. The youth protection law in Germany just regulates sale of alcohol, or serving alcohol in public, or letting underage people consume alcohol in a public bar/restaurant.
Now, at some point, the German version of CPS might raise an eyebrow if a childs health is in danger, but that's another issue.
Maybe that works with someone willing to take advice, but flying blind is a different story.
Usually, industrial radiography equipment is fairly unforgiving to people who aren't willing to learn. Maybe leaving said manager alone with the equipment, just for a few minutes, would have resolved the issue.
Train the H1-B to completely F* up every possible aspect of the job would be my parting gift tot he company.
That's bound to backfire. Legally.
Personally, I'd include in my contract that training replacements is explicitly not part of my job description unless a) there is sufficient time for proper training (say, 12 months or so), or b) the replacement is necessary because I'm quitting the job.
ARM thinks that this is valid under certain circumstances and provides an appropriate setting in their CPUs (DIV_0_TRAP).
Would they do that if it was completely useless?
Statistically, returning zero usually yields less horrible consequences than returning an arbitrary non-zero number.
If the result of the division is used in further calculations, e.g. in a product, a zero won't cause additional undefined behavior by signed integer overflows, etc.
Depends on the code. If dividing by zero results in occasional audio glitches, it's not horribly broken. If dividing by zero results in the code occasionally killing people, it's horribly broken.
Depends on your CPU. It may have a setting to make it just return zero when dividing by zero. Sometimes, that's less harmful than other options.
It can be expanded to (0*1)/0 and then to 0*(1/0), since anything multiplied by one is itself.
Of course, you need to get down to assembly to mess with this setting, since most programming languages specify a behavior in this case, or behave in an unspecificed way.
Then again, dividing by zero usually means that there's something wrong with your design.
Please explain under which condition(s) the code
will dereference a null pointer.
And let's be tooooootally impartial. What could go wrong?
The construct is similar, but not identical. The difference is significant, though.
Power, noise, heat ...
Finding a potential problem through static code analysis and fixing it before the release is usually much cheaper than finding the problem in the wild, tracking down the bug, fixing it, and patching everything that's out there.
If you haven't encountered hand-soldered transistors, you haven't gone "down" far enough.
I can see why one of the MISRA rules states that "limited dependence" should be placed on C operator precedence and expressions should be clarified (to the reader, not to the compiler) by using parentheses.
No, it's not. The stuff that kills you if you stand next to it has half-lives below 50 years, which means that after one or two thousand years, there's hardly anything left of the original amount.
The isotopes with half-lives in the thousands of years don't emit enough radiation to give someone deadly radiation poisoning in a few minutes, but they will raise cancer rates if released into the environment at any point in the next couple of hundred thousand years.
I guess you don't need to inflate small asteroids on a regular basis?
Things get really confusing when you omit the prefix on microphone ... or Microsoft.
In unrelated news: 'm' is not an abbreviation of 'micron'.
These researchers had physical control of the hardware in question and were able to extract unencrypted data? That must have been difficult.
Actually, drinking is legal in Germany regardless of age. The youth protection law in Germany just regulates sale of alcohol, or serving alcohol in public, or letting underage people consume alcohol in a public bar/restaurant.
Now, at some point, the German version of CPS might raise an eyebrow if a childs health is in danger, but that's another issue.
On the other hand, you'll have to deal with German, Germans, Germany and their respective quirks.
Any development methodology that's guaranteed to work should be viewed with a healthy dose of suspicion.
Usually, industrial radiography equipment is fairly unforgiving to people who aren't willing to learn. Maybe leaving said manager alone with the equipment, just for a few minutes, would have resolved the issue.
You just need to fake it until you get your first golden parachute, and then switch careers, e.g. into politics.
Evidently, some IS people didn't study this particular example of basic security precaution...
That's bound to backfire. Legally.
Personally, I'd include in my contract that training replacements is explicitly not part of my job description unless a) there is sufficient time for proper training (say, 12 months or so), or b) the replacement is necessary because I'm quitting the job.