[tor-bugs] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
--------------------------------------------+------------------------------
 Reporter:  teor                            |          Owner:  (none)
     Type:  defect                          |         Status:  new
 Priority:  Medium                          |      Milestone:  Tor:
                                            |  unspecified
Component:  Core Tor/Tor                    |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed  |  Actual Points:
Parent ID:                                  |         Points:  2
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by riastradh):

 Replying to [comment:4 nickm]:
 > Seems plausible, but could I ask your opinion on the rest of that
 thread, where people are arguing about what's undefined and what isn't?

 There are four main points here:

 1. C99 technically does say of the `/` operator that 'if the value of the
 second operand is zero, the behavior is undefined'.  (C99, Sec. 6.5.5
 Multiplicative operators, clause 5, p. 82)

 2. Annex F specifies that all the arithmetic operations on floating-point
 types have IEEE 754 semantics: 'The `+`, `-`, `*`, and `/` operators
 provide the IEC 60559 [another name for IEEE 754, along with ISO/IEC 559]
 add, subtract, multiply, and divide operations.'  (C99, Annex F, F.3
 Operators and functions, p. 445)

 3. Strictly speaking, Annex F is optional.  Strictly speaking, there may
 be bugs in the IEEE 754 conformance of clang or gcc.  Strictly speaking,
 not everything is up to the compiler, so if you used clang or gcc but
 linked against a broken libm that didn't provide IEEE 754 semantics, it
 might be technically wrong for clang or gcc to advertise IEEE 754
 semantics (a.k.a. Annex F support, indicated by the definition of the
 `__STDC_IEC_559__` macro).

 4. Nobody except a disingenuous language lawyer trolling for a point would
 seriously choose to make clang or gcc deviate in any substantial way from
 IEEE 754 semantics.
  Essentially the entire body of numerical software on the planet of the
 past quarter century, outside now-obscure platforms like legacy IBM
 mainframes or VAXes, has been designed under the premise of IEEE 754
 semantics.  Even clang UB optimization attorneys, who might delete null
 pointer checks if they can be proven to follow undefined behaviour in the
 absence of `-fno-delete-null-pointer-checks`, don't seem to be inclined to
 take advantage of the potential room for disagreement between C99 6.5.5
 and Annex F.

 For an illustrative example of the value of IEEE 754 semantics, see the
 dozens of cases in #29527 that could have gone wrong if we didn't have
 IEEE 754 divide-by-zero semantics, but that do exactly the right thing
 even though I wasn't thinking about those cases when I wrote the code
 (until I wrote the test cases, and again later when I reviewed all the
 false positives).  Failure to support IEEE 754 semantics, particularly
 extremely basic parts like consistently giving infinities for division by
 zero, would likely be blamed for [[http://www-
 users.math.umn.edu/~arnold/disasters/ariane5rep.html|billion-dollar
 mistakes]].

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29528#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online