https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Andrew Pinski changed:
What|Removed |Added
Target Milestone|6.5 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Richard Biener changed:
What|Removed |Added
Target Milestone|6.4 |6.5
--- Comment #38 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|6.3 |6.4
--- Comment #37 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Richard Biener changed:
What|Removed |Added
Target Milestone|6.2 |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Richard Biener changed:
What|Removed |Added
Target Milestone|6.2 |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Richard Biener changed:
What|Removed |Added
Target Milestone|6.2 |6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|6.0 |6.2
--- Comment #36 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #35 from Alexander Cherepanov ---
On 2015-11-20 04:06, joseph at codesourcery dot com wrote:
>> What does the following mean then?
>>
>> C11, 4p5:
>> "A strictly conforming program[...] It [...] shall not exceed any
>> minimum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #34 from joseph at codesourcery dot com ---
On Thu, 19 Nov 2015, ch3root at openwall dot com wrote:
> What does the following mean then?
>
> C11, 4p5:
> "A strictly conforming program[...] It [...] shall not exceed any
> minimum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #33 from Alexander Cherepanov ---
On 2015-11-12 06:25, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
>
> --- Comment #31 from Martin Sebor ---
> (In reply to Alexander Cherepanov from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #32 from Alexander Cherepanov ---
Sorry for the late reply. Decided to read DR 260 and got distracted. It
so fundamentally undermines the base of classical C that it took me some
time to grasp the scale:-)
On 2015-11-12 01:51,
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 #26 from Eric Botcazou ---
> Sure. I'm pointing out that Windows has had safety here for years, while
> Linux doesn't.
Thanks for correcting, the initial formulation was quite misleading and could
be understood as GCC not being on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #29 from Alexander Cherepanov ---
On 2015-11-11 14:57, ebotcazou at gcc dot gnu.org wrote:
>> Are you saying that -fstack-check is ready for use? Why it's not
>> documented (except for Ada and in gccint)?
>
> !??? See 3.18 Options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #27 from Alexander Cherepanov ---
On 2015-11-11 11:16, ebotcazou at gcc dot gnu.org wrote:
> On 2015-11-11 03:36, danielmicay at gmail dot com wrote:
>> The implementation of -fstack-check in GCC does have significant overhead,
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #28 from Eric Botcazou ---
> Are you saying that -fstack-check is ready for use? Why it's not
> documented (except for Ada and in gccint)?
!??? See 3.18 Options for Code Generation Conventions in the manual.
> According to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #31 from Martin Sebor ---
(In reply to Alexander Cherepanov from comment #23)
> 2. The practical problem is size calculation in general, it's not
> limited to sizeof operation. You don't need to use sizeof to create
> oversized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #30 from joseph at codesourcery dot com ---
On Wed, 11 Nov 2015, ch3root at openwall dot com wrote:
> 4. From the POV of the standard I don't see much difference between VLA
> and ordinary arrays in this question. AFAICT the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #24 from Eric Botcazou ---
> Stack overflow is undefined with GCC, but MSVC++ and Clang on Windows
> guarantee that it will be caught if the program doesn't invoke any truly
> undefined behavior.
Just as GCC on Windows...
> The
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 #20 from joseph at codesourcery dot com ---
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
normal C practice in areas such as stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #22 from Martin Sebor ---
(In reply to jos...@codesourcery.com from comment #20)
> where the C
> standard fails to recognize limits in such areas but all implementations
> in practice have such limits, that's a defect in the C
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=68065
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #23 from Alexander Cherepanov ---
On 2015-11-11 03:53, msebor at gcc dot gnu.org wrote:
> Another way is that the standard requires
> sizeof(excessively-large-vla-type) to overflow/wrap. That's how the
> implementations I've tested
27 matches
Mail list logo
