[llvm-dev] GEP with a null pointer base

[James Y Knight via llvm-dev]

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
> that
> > 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.  */

#ifdef __PTRDIFF_TYPE__
# define PTR_INT_TYPE __PTRDIFF_TYPE__
#else
# include <stddef.h>
# define PTR_INT_TYPE ptrdiff_t
#endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/2a5a8ff3/attachment.html>