https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #28 from Daniel Micay ---
I got jemalloc / Bionic libc (Android) to report errors for malloc and
mmap/mremap larger than PTRDIFF_MAX a while ago (along with fixing a missing
case for mremap in musl), but glibc needs to be convinced to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #25 from Alexander Cherepanov ---
On 28.10.2015 03:12, joseph at codesourcery dot com wrote:
>> What is missing in the discussion is a cost of support in gcc of objects
>> with size > PTRDIFF_MAX. I guess overhead in compiled code wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #24 from joseph at codesourcery dot com ---
I suppose that while EXACT_DIV_EXPR on the individual halves of a
subtraction wouldn't be correct, it would also be correct (given any
constant element size) to do the (right shift, multip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #23 from Rich Felker ---
I think you can always do the right-shift first. Pointer subtraction is
undefined unless both pointers point to elements of the same array, and the
addresses of elements of an array will inherently be congruen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #22 from joseph at codesourcery dot com ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:
> What is missing in the discussion is a cost of support in gcc of objects
> with size > PTRDIFF_MAX. I guess overhead in compiled c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #21 from Alexander Cherepanov ---
On 2015-10-21 06:21, danielmicay at gmail dot com wrote:
>> I think several issues are mixed:
>
> A conforming C implementation requires either fixing both the compiler and
> libc
> functions to hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #20 from Daniel Micay ---
> I think several issues are mixed:
A conforming C implementation requires either fixing both the compiler and libc
functions to handle > PTRDIFF_MAX objects or preventing them from being
allocated via stand
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #18 from Alexander Cherepanov ---
I guess nobody doubts that the current situation in gcc+glibc (and clang+glibc)
should be fixed as valid programs are miscompiled. And it's easy to imagine
security consequences of this when buffers h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #16 from Richard Biener ---
GCC assumes objects will not wrap around zero only (well, it assumes objects
cannot live at address zero but it also assumes that the
pointer-to-one-element-after isn't zero or wraps around zero).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #15 from Daniel Micay ---
i.e. AFAIK the offsets are intended to be treated as signed but treating
pointers as signed would be a serious bug rather than a design choice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #14 from Daniel Micay ---
(In reply to Florian Weimer from comment #12)
> (In reply to Daniel Micay from comment #10)
> > (In reply to Florian Weimer from comment #7)
> > > If this is not a GCC bug and it is the responsibility of allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #13 from Daniel Micay ---
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. Of course,
they'd have to be very careful to avoid all of the cave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #12 from Florian Weimer ---
(In reply to Daniel Micay from comment #10)
> (In reply to Florian Weimer from comment #7)
> > If this is not a GCC bug and it is the responsibility of allocators not to
> > produce huge objects, do we also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #11 from Florian Weimer ---
(In reply to Daniel Micay from comment #9)
> I don't think there's much of a use case for allocating a single >2G
> allocation in a 3G or 4G address space.
The main OpenJDK heap (well, it was Java back th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #10 from Daniel Micay ---
(In reply to Florian Weimer from comment #7)
> If this is not a GCC bug and it is the responsibility of allocators not to
> produce huge objects, do we also have to make sure that no object crosses
> the boun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #9 from Daniel Micay ---
(In reply to Florian Weimer from comment #8)
> (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 rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #8 from Florian Weimer ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Daniel Micay changed:
What|Removed |Added
CC||danielmicay at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #4 from Alexander Cherepanov ---
Interesting. In particular, this means that the warning "Argument 'size' of
function malloc has a fishy (possibly negative) value" from valgrind is a
serious thing. Is this gcc limitation documented so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #3 from Andreas Schwab ---
Did you mean ptrdiff_t?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #2 from Andrew Pinski ---
ssize_t is a signed integer and in the case of x86, it is 32bits which means
exactly what Marc wrote.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #1 from Marc Glisse ---
I don't think gcc supports using more than half the address space in a single
allocation. At least I've seen reports of bugs in the past, and I seem to
remember people not being very concerned...
28 matches
Mail list logo
