https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479
Daniel Micay danielmicay at gmail dot com changed:
What|Removed |Added
CC||danielmicay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265
Daniel Micay danielmicay at gmail dot com changed:
What|Removed |Added
CC||danielmicay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Daniel Micay changed:
What|Removed |Added
CC||danielmicay at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #25 from Daniel Micay ---
> Just as GCC on Windows...
Sure. I'm pointing out that Windows has had safety here for years, while Linux
doesn't. It should. It really shouldn't be possible to exploit well-defined
code. Running out of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #17 from Daniel Micay ---
It's well-defined C code though. It shouldn't be possible to for anything to go
wrong here when using -fstack-check, i.e. it should be guaranteed to trigger a
stack overflow which is caught. The size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #18 from Daniel Micay ---
Also, it's possible to use segmented stacks to avoid stack overflow and this
probably breaks in that context too. That's a very niche use case compared to
-fstack-check though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #21 from Daniel Micay ---
(In reply to jos...@codesourcery.com from comment #20)
> Undefined behavior when the type is created (not when an object of that
> type is declared or when sizeof is used) seems entirely in accordance with
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 #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
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 #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
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
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
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
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: danielmicay at gmail dot com
Target Milestone: ---
The __builtin_object_size intrinsic is primarily used for _FORTIFY_SOURCE,
where it's used
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090
--- Comment #2 from Daniel Micay ---
This has now been implemented in Clang as __builtin_dynamic_object_size.
There's a thread on the GCC mailing list about it at
https://www.mail-archive.com/gcc@gcc.gnu.org/msg87230.html.
17 matches
Mail list logo
