[PATCH] D48958: [clang][ubsan] Implicit Cast Sanitizer - integer truncation - clang part

Roman Lebedev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 30 14:01:38 PDT 2018

lebedev.ri 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
rsmith wrote:
> 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.
Ok, with that additional explanation, i do see the error of my ways, and will re-adjust the docs accordingly.

  rC Clang


More information about the cfe-commits mailing list