On 09/05/18 23:50, Ian Zimmerman wrote:
Code may be "security-sensitive" but buggy. Is the compiler writer
really responsible for guessing what the programmer meant to accomplish
with buggy code?
What do you mean by "buggy"?
It would of course be preferable if the compiler could
just abort with an error when it detects UB, but that turns out to be
very hard to impossible in the case of C. That's just a built in
problem with the language.
So if the compiler can't detect undefined behaviour, how the hell do you
expect the programmer to?
Oh - and please explain - what is buggy about wanting the following
program to compile and actually *do* what the code is asking, rather
than compiling to a no-op ...
int main () {
int a, b, c;
a = 2;
b = 4;
c = 6;
}
Note I did say the problem is almost invariably when hardware gets
involved - what happens if it's
int main () {
void *a;
a = 0x00ff;
*a = 6;
}
and 0x00ff is the address of your network adaptor? Do you want THAT to
be optimised away "because it doesn't do anything"?
That's why I expect LVM/Clang is much better - because I believe Intel
is heavily involved they provide guarantees about how the compiler will
interact with hardware, when the C standard explicitly avoids specifying
it (imho, the standard should require a compiler to document how it
handles things like that ...). (Yes I believe there is some compiler
option to make that work, but I'm pretty certain that either is or was
undefined behaviour to start with? And if it is now standard, it's
probably because some clever idiot optimised the "code which doesn't do
anything" away and they had to define a way of stopping it?)
Cheers,
Wol
