> A conforming implementation may chose to melt your computer - and you can choose to not use that implementation. But clang and gcc will never melt your Linux.
And for the 3rd time, a real world case that might ruin your computer is an embedded device without memory protection.
This has nothing to do with memory protection.
If a process has the ability to do something, then it may do so. It wouldn't be because GCC and clang choose to melt your computer, it is because your program has a bug, and the consequences of that bug can be anything, including jumping into random executable code that happens to ruin the computer.
> If a process has the ability to do something, then it may do so
You agree with me. Once again, on an embedded device writing over a buffer may do absolutely anything. Thanks to memory protection, what a process can do is more limited. The C spec is written for both cases.
No gcc and clang will not insert code to start rm’ing files when you overflow a signed integer.
> gcc and clang will not insert code to start rm’ing files when you overflow a signed integer.
It could. If it detect that a code path cannot be taken without causing overflow, it will assume this code path cannot be taken and will optimise it by removing it. No need even to return from the function.
If you reach this code anyway, it can run whatever functions is on the binary after it. If you're unlucky that's a function to remove temporary files which would be ran with bogus arguments.
> A conforming implementation may chose to melt your computer - and you can choose to not use that implementation. But clang and gcc will never melt your Linux.
And for the 3rd time, a real world case that might ruin your computer is an embedded device without memory protection.