[llvm-dev] GEP with a null pointer base
Florian Weimer via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 7 00:29:19 PDT 2017
* Erich Keane:
> Responded to this earlier but didn't get llvm-dev on the list:
>
> This is the commit that caused the newest revision of the problem:
> https://github.com/lattera/glibc/commit/2fd4de4b15a66f821057af90714145d2c034a609
For posterity:
commit 2fd4de4b15a66f821057af90714145d2c034a609
Author: Roland McGrath <roland at gnu.org>
Date: Wed Jan 11 05:43:11 2006 +0000
[BZ #321]
2005-10-14 Paul Eggert <eggert at cs.ucla.edu>
…
[BZ #321]
Fix portability bugs encountered when porting to Itanium.
* malloc/obstack.h (obstack_empty_p, obstack_finish): Do not
assume that the "contents" member is suitably aligned. It is
not, for some hosts and alignments: e.g., Itanium, long-double.
* malloc/obstack.c (_obstack_begin, _obstack_begin_1,
_obstack_newchunk): Likewise.
* malloc/obstack.c: Include <stddef.h>, for size_t.
Include <inttypes.h>, <stdint.h> if needed and available.
(DEFAULT_ALIGNMENT): Now an enum constant, not a macro.
Use C89 offsetof rather than K&R trick.
Use the maximum alignment of uintmax_t, long double, void *
rather than the alignment of double.
(union fooround): Use uintmax_t, long double, void * members
rather than just long and double.
[BZ #321]
Fix portability bugs encountered when porting to the IBM iSeries,
where pointers are 256 bits wide and no integers are that wide.
* malloc/obstack.h (__PTR_TO_INT, __INT_TO_PTR): Remove.
All uses changed to:
(__BPTR_ALIGN, __PTR_ALIGN): New macros.
(struct _obstack_chunk.temp): Change from int to a union
of pointer and int. All uses changed.
The referenced bug is here:
https://sourceware.org/bugzilla/show_bug.cgi?id=321
I don't doubt that alignment code is needed. The new allocation
buffers I wrote for glibc have that as well, hopefully in a slightly
more portable manner. But the workaround added at the time to
<obstack.h> (and which is still used today) doesn't seem quite right.
Fortunately, all our targets have uintptr_t and pretty much a flat
address space.
If someone could provide a minimal test case with #include <obstack.h>
and the Clang version(s) that exhibit the problem, I can file
something in glibc Bugzilla to track this at least.
More information about the llvm-dev
mailing list