[llvm-dev] GEP with a null pointer base
Florian Weimer via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 13:06:13 PDT 2017
* Andrew via llvm-dev Kaylor:
> The most recent glibc code is a bit more complicated than I
> represented below. If you look up obstack.h you can see what’s there
> now. Basically, they’re computing a pointer alignment that may be
> based on some non-null base pointer or may be based on null, depending
> on the target architecture. I’m sure it’s possible to make it more
> sensible, but I’ve never interacted with the glibc community so I’m
> not sure how open they would be to changing this. I suspect I’d need
> a more compelling argument than clang-compatibility (or maybe even
> standards compatibility).
Not at all, we are fine with making installed headers more palatable
to a wider range of compilers.
That being said, I find obstacks rather horrible and wouldn't be
surprised if they can't be implemented in a standard-conforming
manner. Strictly speaking, you can't take a pointer, convert it to
(u)intptr_t, twiddle some bits for alignment purposes, and cast it
back to get another object pointer. But it seems to me that obstacks
go beyond that in terms of C language abuse.
The offset relative to NULL was probably needed for some old
compilers. We should rewrite this using uintptr_t and __alignof__.
If anyone wants to work on this and change the macros, we'd definitely
review a patch submission (if it is short enough or is backed by a
copyright assignment, sorry).
More information about the llvm-dev