Can an undefined read operation cause a crash elsewhere?

[jl_post]

Dear C++ community,

You know how sometimes an action that can cause a crash doesn't
always crash, but can cause undefined behavior later in the program?
Well, my question is: If an undefined read-only operation somehow
avoids crashing, can it still cause a crash later in unrelated code?

Allow me to illustrate with a pseudo-program:

#include <iostream>
#include <vector>

int main(int argc, char ** argv)
{
// Part A: Find the biggest element of an array.
{
std::vector<unsigned int> array; // empty array!
unsigned int biggestElement = 0;

for (unsigned int i = 0; i < 100; i++)
{
// Since array is empty, the following lines are
// undefined behavior, and could cause a crash:
if (array > biggestElement)
biggestElement = array;
}

std::cout << "Biggest element is: "
<< biggestElement << std::endl;
}

// Part B: Do everything else.
std::cout << "Hello, world!" << std::endl;
// (Lots of code goes here.)

return 0;
}


In this program, the for-loop in Part A iterates 100 times over an
empty array. Many programmers would expect this to crash, but as with
many undefined behaviors, a crash is not guaranteed to happen; the
program could conceivably "survive" and make it into Part B.

Notice that Parts A and B are independent: nothing is carried over
from Part A that can affect the logic of Part B. Knowing this fact,
if the program does indeed make it to Part B, could Part B still crash
(or produce undefined behavior) simply because of the array-bounds
read error in Part A?

In other words, could the read-only error in Part A conceivably
corrupt memory (and cause a crash) for Part B, even though they share
independent logic?

(I'm asking this question because I want to know if undefined read-
only behavior (that does not corrupt the program logic) can corrupt
memory that can cause further problems later in the program's
execution.)

Thanks,

-- Jean-Luc

 

[crisgoogle]

Dear C++ community,

   You know how sometimes an action that can cause a crash doesn't
always crash, but can cause undefined behavior later in the program?
Well, my question is:  If an undefined read-only operation somehow
avoids crashing, can it still cause a crash later in unrelated code?

   Allow me to illustrate with a pseudo-program:

#include <iostream>
#include <vector>

int main(int argc, char ** argv)
{
   // Part A:  Find the biggest element of an array.
   {
      std::vector<unsigned int> array;  // empty array!
      unsigned int biggestElement = 0;

      for (unsigned int i = 0; i < 100; i++)
      {
         // Since array is empty, the following lines are
         // undefined behavior, and could cause a crash:
         if (array > biggestElement)
            biggestElement = array;
      }

      std::cout << "Biggest element is: "
                << biggestElement << std::endl;
   }

   // Part B:  Do everything else.
   std::cout << "Hello, world!" << std::endl;
   // (Lots of code goes here.)

   return 0;

}

   In this program, the for-loop in Part A iterates 100 times over an
empty array.  Many programmers would expect this to crash, but as with
many undefined behaviors, a crash is not guaranteed to happen; the
program could conceivably "survive" and make it into Part B.

   Notice that Parts A and B are independent: nothing is carried over
from Part A that can affect the logic of Part B.  Knowing this fact,
if the program does indeed make it to Part B, could Part B still crash
(or produce undefined behavior) simply because of the array-bounds
read error in Part A?

   In other words, could the read-only error in Part A conceivably
corrupt memory (and cause a crash) for Part B, even though they share
independent logic?

   (I'm asking this question because I want to know if undefined read-
only behavior (that does not corrupt the program logic) can corrupt
memory that can cause further problems later in the program's
execution.)

   Thanks,

   -- Jean-Luc

Short answer to your final question: yes.

You're terminology is a little loose: undefined behaviour in one part
of the code doesn't _cause_ undefined behviour in other parts of the
code,
as you seem to imply.

More correctly, the _program_ has undefined behaviour. Therefore,
anything
can happen at any time: the program may not compile, it may run
"perfectly",
it can produce bogus results, it can crash at any arbitrary point in
time.

So yes, the bogus reads could cause a crash later in time. Any
mechanisms
by which this might happen in a real implementation seem kinda far-
fetched
to me, but not inconceivable: what if the bogus reads stray onto
memory
that has some specific behaviour just due to being read? That
behaviour
could put the program into a state that only crashes when the
"unrelated"
code later on is executed. If you hadn't lied to the compiler about
the
size of the array, it would have known not to put it where a valid
read
would cause the behaviour I suggest above.

 

[Drew Lawson]

Others have addressed your base question. I just wanted to stomp
on a bug crawling across your vocabulary.

std::vector<unsigned int> array; // empty array!

Your comment is wrong.
This is not an empty array. It is an empty vector.

Most questions about one do not yield answers applicable to the other.