RE: US-CERT Vulnerability Note VU#162289

["Dave Korn" <dave dot korn at artimi dot com>]

Robert Dewar wrote on :

> One thing to realize in this discussion is that it is not
> possible in general to warn when a programmer is depending
> on undefined behavior, since by definition you cannot in
> general guess what misunderstandings the programmer has
> about C, and hence what behavior is expected.
> 
> There are some cases where you can guess well enough that
> you can provide warnings that won't have an excessive
> number of annoying false positivesm, and warnings in
> such cases are appropriate.
> 
> But some contributions to this thread have seemed to
> come near to a position of requiring warnings whenever
> the compiler does something that might violate expectations
> of a programmer writing undefined C code, and as a general
> principle this is fundamentally impossible.


  And some have been pleas for the compiler to DWIM.  Which, while it would be
nice, is not just impossible, but conceptually flawed to the point of
meaninglessness because it begs the question.  This is because whatever the
compiler assumes you /actually/ meant when it's trying to DWYM would have to
be based on a set of rules/heuristics/inferences that would be just as liable
as the current optimisation vs. undefined behaviour rules to misunderstandings
that end up introducing security violations - but with the added disadvantage
of not being in accord with a well-defined standard of behaviour, but being
some ad-hoc and unpredictable set of transformations that you can't even know
to avoid.

  In short, any attempt by the compiler to DWIM would just move the same class
of problem around, but make it harder to detect; a lose-lose situation for
everyone.  At least with a clear standard, it's possible to make guarantees
about when and whether a program is correct or not.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....