Are you really sure that all the C code the two of you have written in your careers carefully avoids all 191 kinds of undefined behavior in C99 (the number has grown since then)?  Give me leave to doubt it. 

Consider this example from an earlier version of the Linux kernel:

static void __devexit agnx_pci_remove (struct pci_dev *pdev)
{
  struct ieee80211_hw *dev = pci_get_drvdata(pdev);
  struct agnx_priv *priv = dev->priv;

  if (!dev) return;
  ... do stuff using dev ...
}

The trouble here is that dev is used before it is checked for being a null pointer.  In Java, you'd have a NullPointerException.  In C, "gcc -O2" will make this analysis:

Case 1: dev == NULL.  This is undefined behavior and the compiler has no obligations.

Case 2: dev != NULL.  Since dev can't be null (the compiler always assumes the programmer did not intend to use UB), the check can be removed.

The result is that there is no check for NULL in either case, the compiler is silent, and since this is the kernel, dereferencing NULL probably pwns your system.  So whereas things that were technically UB used to work more or less as you'd expect them to, nowadays they work as *nobody* expects them to.

This is the result of the three values of C programmers:  (1) fast execution, (2) fast compilation, (3) I lied; there is no (3).  And as optimizers get better and better, the number of UB-related disasters increases.  (The same is true for C++ compiler developers, except that they sometimes prioritize (2) over (1) because benchmarks.)

See <https://blog.regehr.org/archives/1287>, about how an attempt to reduce the amount of UB int C failed because nobody could agree with anybody else on what changes to make.

C++, is it?  C++2011 has 203 UBs.