rsmith added inline comments.
================ Comment at: docs/UndefinedBehaviorSanitizer.rst:136-137 + overflow happens (signed or unsigned). + Both of these two issues are handled by ``-fsanitize=implicit-conversion`` + group of checks. - ``-fsanitize=unreachable``: If control flow reaches an unreachable ---------------- lebedev.ri wrote: > rsmith wrote: > > I don't think that's true (not until you add a sanitizer for signed <-> > > unsigned conversions that change the value). `4U / -2` produces the > > unexpected result `0U` rather than the mathematically-correct result `-2`, > > and `-fsanitize=implicit-conversion` doesn't catch it. Maybe just strike > > this sentence for now? > > > > In fact... I think this is too much text to be adding to this bulleted > > list, which is just supposed to summarize the available checks. Maybe > > replace the description with > > > > Signed integer overflow, where the result of a signed integer > > computation cannot be represented in its type. This includes all the checks > > covered by ``-ftrapv``, as well as checks for signed division overflow > > (``INT_MIN/-1``), but not checks for lossy implicit conversions performed > > before the computation (see ``-fsanitize=implicit-conversion``). > I will assume you meant "lossy implicit conversions performed *after* the > computation". I really meant "performed before", for cases like `4u / -2`, where `-2` is implicitly converted to `UINT_MAX - 2` before the computation. Conversions that are performed after a computation aren't part of the computation at all, so I think it's much clearer that they're not in scope for this sanitizer. Repository: rC Clang https://reviews.llvm.org/D48958 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
