[llvm-dev] GEP with a null pointer base
James Y Knight via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 15:33:29 PDT 2017
On Thu, Jul 6, 2017 at 5:49 PM, Florian Weimer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> * James Y. Knight via llvm-dev:
> > To the first, asking people who do crazy stuff like this to compile with
> > -fno-strict-overflow is reasonable...they're invoking C-level undefined
> > behavior by doing arbitrary pointer-math, so they should use the flag
> > tells the compiler to make arbitrary pointer-math not be UB.
> Bit this comes from a glibc header, so ideally, it should be fixed to
> work with all compiler modes (with the caveat that some things that
> obstack does may never be valid C code).
Yes, no matter what clang does, this header should be fixed to not align
pointers an extraneously-weird-and-broken way. On platforms where uintptr_t
exists, just do the straightforward obvious math that _everyone else_ uses.
On platforms where it doesn't exist (like I guess this IBM thing?), the
existing code, path where it subtracts an actual base object is fine...
Also, gotta love this code snippet below. It wants to avoid "polluting the
namespace" by including stddef.h (really???), and thus proceeds to define a
global macro in the user namespace called "PTR_INT_TYPE". Ha ha very funny!
/* We need the type of a pointer subtraction. If __PTRDIFF_TYPE__ is
defined, as with GNU C, use that; that way we don't pollute the
namespace with <stddef.h>'s symbols. Otherwise, include <stddef.h>
and use ptrdiff_t. */
# define PTR_INT_TYPE __PTRDIFF_TYPE__
# include <stddef.h>
# define PTR_INT_TYPE ptrdiff_t
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev