[all-commits] [llvm/llvm-project] 39431e: [clang-tidy] Introduce misc No Integer To Pointer ...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 39431e479ffddc81120911f031921b2d637e967f
      https://github.com/llvm/llvm-project/commit/39431e479ffddc81120911f031921b2d637e967f
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-12-08 (Tue, 08 Dec 2020)

  Changed paths:
    M clang-tools-extra/clang-tidy/performance/CMakeLists.txt
    A clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.cpp
    A clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.h
    M clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
    M clang-tools-extra/docs/ReleaseNotes.rst
    M clang-tools-extra/docs/clang-tidy/checks/list.rst
    A clang-tools-extra/docs/clang-tidy/checks/performance-no-int-to-ptr.rst
    A clang-tools-extra/test/clang-tidy/checkers/performance-no-int-to-ptr.c
    A clang-tools-extra/test/clang-tidy/checkers/performance-no-int-to-ptr.cpp

  Log Message:
  -----------
  [clang-tidy] Introduce misc No Integer To Pointer Cast check

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://www.cs.utah.edu/~regehr/oopsla18.pdf | 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. ]]

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D91055