Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2211

Re: Optimization techniques

Show all headers | View raw

On 25/04/19 20:58, David Brown wrote:
> It is a serious mistake to mix up "defined behaviour" and "correct
> behaviour".  Only defined behaviour can be correct, but you can't fix
> incorrect code by making it defined behaviour.

"Defined behaviour" *can* be "correct behaviour"
"undefined behaviour" can *never* be correct and therefore
must be avoided at all costs.

You dismiss cases of security holes due to undefined behaviour
as "just program bugs, because programmers didn't do the right thing".
The C ANSI standard is over 500 pages long and includes 199
different cases of undefined behaviour. A quick quiz:
without referencing the standard, how many of the 199 cases
of undefined behaviour can you list off the top of your head?
Remember: a *good* programmer (one that you would describe
as an engineer who knows what they are doing) must avoid
all 199 cases of undefined behaviour in every line of code
that they write.

Dijkstra wrote this in his ACL Turing Award Lecture in 1972:

"Using PL/1 must be like flying a plane with 7000 buttons, switches
and handles to manipulate in the cockpit.  I absolutely fail to see
how we can keep our growing programs firmly within our intellectual
grip when by its sheer baroqueness the programming language -- our
basic tool, mind you! -- already escapes our intellectual control."

Note that even knowing that there is undefined behaviour, you still
may not be able to avoid it by testing for its occurrence: the
optimiser might spot that you are testing for undefined behaviour and
optimise away your test, because it is allowed to assume that the
undefined behaviour can never happen!  (This is what actually occurred
in the last example I gave).

You say "The trick is to write the tests correctly" but don't tell us
what clever tricks we can use in order to fool the optimised into
thinking we are testing for something *other* than undefined behaviour
and so head it off from optimising away our test.  Even if we manage
this: how can we be sure that the next version of the compiler will
not include a cleverer optimiser which sees through our trickery and
optimises away the test once again?  There seems to be an arms race
between programmers trying to write safe code and compiler writers
detecting and optimising away their safety nets.

--
			Martin

Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

Back to comp.compilers | Previous | Next — Next in thread | Find similar

Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-26 19:46 +0100
  Re: language design and Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 21:06 +0000
  Re: Optimization techniques and consistent results David Brown <david.brown@hesbynett.no> - 2019-04-29 16:31 +0200
  Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-05-02 10:56 +0100
    Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:51 +0000

csiph-web