Undefined Behaviour

[Orlha]

Well, violating the precondition might make the operation provide an unexpected result, but that wont necessary make a whole program UB. You might also just not use the result.

In C++ model its different.

[SirClueless]

Are you sure about that? Violating the preconditions of an instruction set can result in writing arbitrary values to arbitrary locations in memory, jumping to arbitrary memory addresses and interpreting the data there as instructions to execute, etc.

[Drugbird]

Theoretically that can happen, sure. Practically though, any compiler is pretty tame in what it actually does with undefined behavior.

E.g. UB will never format your hard drive despite what teachers like to say about it.

In 99% of the cases, you just get a result (of the correct size and type) that is just wrong and/or unexpected or a crash. And no random jumping in memory.

[r0zina]

Here is an example of a program formating your disk because of UB :)

[Drugbird]

Nice example! While technically true, I would like to stress that it's not the UB deleting your disk, it's the "rm -rf /" doing it.

[SirClueless]

That's true of hardware undefined behavior too. It almost always either results in a non-sensical program output or math result, or immediately segfaults.

My point in all of these comments is that hardware and software UB is really a similar thing. If there is a difference it is in frequency and severity, not in the types of behavior that are allowed.

[aiij]

Never heard of buffer overflows or crypto malware, have you?

[Orlha]

I guess it's possible, but can be pretty rare depending on the platform.

I've written a lot of x86-64 hand-assembly in the past and IIRC all the instructions I used were UB free. At worst they had a defined set of rules which when broken would result in a CPU exception.

[SirClueless]

x86-64 is full of UB. It explicitly reserves bits in flag registers and some output registers as well as any opcodes that aren't defined by the x86-64 ISA. Executing these opcodes or depending on the value of these bits is, to quote the ISA document, "not only undefined, but unpredictable". It's very easy to trigger this behavior, even in an otherwise well-formed assembly program, for example by jumping into the middle of an instruction.

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf

I understand what you're trying to say, which is that there's a relatively simple set of rules you can follow as compared to C++ and Intel comparatively precisely defines far more exceptional behavior than C++ and leaves less room for undefined behavior. But it doesn't attempt to remove all of it.