This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/67999] Wrong optimization of pointer comparisons
- From: "fw at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 19 Oct 2015 08:25:58 +0000
- Subject: [Bug c/67999] Wrong optimization of pointer comparisons
- Auto-submitted: auto-generated
- References: <bug-67999-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #8 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Alexander Cherepanov from comment #4)
> Am I right that the C standards do not allow for such a limitation (and
> hence this should not be reported to glibc as a bug) and gcc is not
> standards-compliant in this regard? Or I'm missing something?
The standard explicitly acknowledges the possibility of arrays that have more
than PTRDIFF_MAX elements (it says that the difference of two pointers within
the same array is not necessarily representable in ptrdiff_t).
I'm hesitant to put in artificial limits into glibc because in the mast, there
was significant demand for huge mappings in 32-bit programs (to the degree that
Red Hat even shipped special kernels for this purpose).