From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87021 invoked by alias); 21 Oct 2015 02:18:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 86963 invoked by uid 48); 21 Oct 2015 02:18:55 -0000 From: "ch3root at openwall dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/67999] Wrong optimization of pointer comparisons Date: Wed, 21 Oct 2015 02:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ch3root at openwall dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg01689.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #19 from Alexander Cherepanov --- (In reply to Daniel Micay from comment #5) > Objects larger than PTRDIFF_MAX are forbidden with musl (malloc, mmap and > friends report ENOMEM and it's explicitly undefined to create them in > another way and use them with libc), Is it documented? > Since glibc's implementations of standard library functions don't handle > objects larger than PTRDIFF_MAX, this can definitely be considered as a > buggy area in glibc. How buggy? Are there bugs filed? Searching for PTRDIFF_MAX finds Zarro Boogs. > FWIW, Clang also treats `ptr + size` with `size > PTRDIFF_MAX` as undefined > for standard C pointer arithmetic because the underlying getelementptr > instruction in LLVM is inherently a signed arithmetic operation. Clang marks This terminology is quite misleading. It's neither signed nor unsigned. Pointer operand is unsigned while offsets are signed. > standard C pointer arithmetic operations as "inbounds", which among other > things makes use of the value returned from wrapping into undefined > behavior. Ok, I've read the doc you linked to in another comment (thanks for that!). "inbound" means that base pointer and all sums of it with offsets should be in bounds of an actual object. And additions are done "with infinitely precise signed arithmetic". This is the same restriction as in C11 which is satisfied in the provided example. (If one large number is a problem replace "buf + len" by "(int *)buf + len / sizeof(int)".) So it should work in Clang? (In reply to Daniel Micay from comment #13) > They'd still be able to make a mmap system call via syscall(...) to avoid > the check, so it seems like it's mostly an ABI compatibility issue. For this to work a compiler have to support for working with huge objects, right? I think several issues are mixed: - support in a compiler for working with huge objects; - support in a libc for creation of huge objects (via malloc etc.); - support in a libc for processing of huge objects. All of them could be tackled separately. Not all combinations are sensible though:-)