On Saturday, 9 July 2016 at 23:44:07 UTC, H. S. Teoh wrote:
On a more technical note, I think eliding the bounds check on
the grounds that shifting by negative x is UB is based on a
fallacy. Eliding a bounds check should only be done when the
compiler has the assurance that the bounds check is not needed.
Just because a particular construct is UB does not meet this
condition, because, being UB, there is no way to tell if the
bounds check is needed or not, therefore the correct behaviour
IMO is to leave the bounds check in. The elision should only
happen if the compiler is assured that it's actually not needed.
To elide simply because negative x is UB basically amounts to
saying "the programmer ought to know better than writing UB
code, so therefore let's just assume that the programmer never
makes a mistake and barge ahead fearlessly FTW!". We all know
where blind trust in programmer reliability leads: security
holes galore because humans make mistakes. Assuming humans
don't make mistakes, which is what this kind of exploitation of
UB essentially boils down to, leads to madness.
There is also a huge practical benefit in leaving such checks
in the code. I've worked a lot in Perl over the last decade,
and one soon finds that it has great error-checking sprinkled
throughout the implementation. Based on that experience, I can
tell you it's tremendously helpful for development efforts if
unexpected problems are detected immediately when they occur,
as opposed to forcing the programmer to debug based on the wild
particles left over after an atom-smashing experiment.
