[PATCH] D91055: [clang-tidy] Introduce misc No Integer To Pointer Cast check

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 9 01:48:02 PST 2020


lebedev.ri created this revision.
lebedev.ri added reviewers: aaron.ballman, njames93, JonasToth.
lebedev.ri added a project: LLVM.
Herald added subscribers: cfe-commits, xazax.hun, mgorny.
Herald added a project: clang.
lebedev.ri requested review of this revision.

While casting an (integral) pointer to an integer is obvious - you just get
the integral value of the pointer, casting an integer to an (integral) pointer
is deceivingly different. While you will get a pointer with that integral value,
if you got that integral value via a pointer-to-integer cast originally,
the new pointer will lack the provenance information from the original pointer.

So while (integral) pointer to integer casts are effectively no-ops,
and are transparent to the optimizer, integer to (integral) pointer casts
are *NOT* transparent, and may conceal information from optimizer.

While that may be the intention, it is not always so. For example,
let's take a look at a routine to align the pointer up to the multiple of 16:
The obvious, naive implementation for that is:

  char* src(char* maybe_underbiased_ptr) {
    uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
    uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
    uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
    return (char*)aligned_intptr; // warning: avoid integer to pointer casts [misc-no-inttoptr]
  }

The check will rightfully diagnose that cast.

But when provenance concealment is not the goal of the code, but an accident,
this example can be rewritten as follows, without using integer to pointer cast:

  char*
  tgt(char* maybe_underbiased_ptr) {
      uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
      uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
      uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
      uintptr_t bias = aligned_intptr - maybe_underbiased_intptr;
      return maybe_underbiased_ptr + bias;
  }

See also:

- D71499 <https://reviews.llvm.org/D71499>
- Juneyoung Lee, Chung-Kil Hur, Ralf Jung, Zhengyang Liu, John Regehr, and Nuno P. Lopes. 2018. Reconciling High-Level Optimizations and Low-Level Code in LLVM. Proc. ACM Program. Lang. 2, OOPSLA, Article 125 (November 2018), 28 pages. <https://www.cs.utah.edu/~regehr/oopsla18.pdf>


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D91055

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/NoIntToPtrCheck.cpp
  clang-tools-extra/clang-tidy/misc/NoIntToPtrCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-no-inttoptr.c
  clang-tools-extra/test/clang-tidy/checkers/misc-no-inttoptr.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D91055.303775.patch
Type: text/x-patch
Size: 11226 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201109/833e7795/attachment.bin>


More information about the llvm-commits mailing list