[llvm-dev] GEP with a null pointer base

[Florian Weimer via llvm-dev]

* 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).