On Wed, Mar 4, 2015 at 12:38 AM, Jeff Law wrote:
> On 03/03/15 12:57, Martin Sebor wrote:
>>
>>
>> As a data point(*) it might be interesting to note that GCC itself
>> relies on memcpy providing stronger guarantees than the C standard
>> requires it to by emitting calls to the function for large
On 03/03/15 12:57, Martin Sebor wrote:
As a data point(*) it might be interesting to note that GCC itself
relies on memcpy providing stronger guarantees than the C standard
requires it to by emitting calls to the function for large structure
self-assignments (which are strictly conforming, as di
On 02/20/2015 10:01 AM, Jeff Law wrote:
On 02/20/15 05:10, Jakub Jelinek wrote:
On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E
On 28/02/2015 9:12 am, Manuel López-Ibáñez wrote:
On 02/19/15 14:56, Chris Johns wrote:
My main concern is not knowing the trap has been added to the code. If I
could build an application and audit it somehow then I can manage it. We
have a similar issue with the possible use of FP registers be
On 02/19/15 14:56, Chris Johns wrote:
>
> My main concern is not knowing the trap has been added to the code. If I
> could build an application and audit it somehow then I can manage it. We
> have a similar issue with the possible use of FP registers being used in
> general code (ISR save/restore t
On Thu, 2015-02-26 at 11:17 -0500, David Malcolm wrote:
> On Fri, 2015-02-20 at 10:29 -0700, Jeff Law wrote:
> > On 02/19/15 14:56, Chris Johns wrote:
> > > On 20/02/2015 8:23 am, Joel Sherrill wrote:
> > >>
> > >> On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
> > >>> Jakub Jelinek wrote:
> >
On Fri, 2015-02-20 at 10:29 -0700, Jeff Law wrote:
> On 02/19/15 14:56, Chris Johns wrote:
> > On 20/02/2015 8:23 am, Joel Sherrill wrote:
> >>
> >> On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
> >>> Jakub Jelinek wrote:
> On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
> >
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> ...
> Regardless, the right thing to do is to disable elimination of NULL pointer
> checks on targets where page 0 is mapped and thus a reference to *0 may not
> fault. In my mind this is an attribute of both the processor (see H8 above)
>
> On Feb 20, 2015, at 12:01 PM, Jeff Law wrote:
>
> On 02/20/15 04:43, Jonathan Wakely wrote:
>>> ...
>>
>> I'm inclined to agree.
>>
>> Most developers aren't aware of the preconditions on memcpy, but GCC
>> optimizes aggressively based on those preconditions, so we have a
>> large and potent
On 02/20/15 10:09, Florian Weimer wrote:
On 02/20/2015 06:01 PM, Jeff Law wrote:
But that's always true -- this isn't any different than aliasing,
arithmetic overflow, etc. The standards define the contract between the
compiler/library implementors and the developers. Once the contract is
bro
On 02/19/15 14:56, Chris Johns wrote:
On 20/02/2015 8:23 am, Joel Sherrill wrote:
On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
Jakub Jelinek wrote:
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths-de
On 02/20/15 04:43, Jonathan Wakely wrote:
On 20 February 2015 at 11:06, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
implicitly
On 02/20/2015 06:01 PM, Jeff Law wrote:
> But that's always true -- this isn't any different than aliasing,
> arithmetic overflow, etc. The standards define the contract between the
> compiler/library implementors and the developers. Once the contract is
> broken, all bets are off.
What I don't
On 02/20/15 05:10, Jakub Jelinek wrote:
On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
i
On 02/20/15 04:06, Florian Weimer wrote:
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
H, Passing the additional option in user code would be one thing,
but what about library code? E.g., using memcpy (either explicitly or
implicitly for a structure copy)?
The memcpy problem isn't rest
On 02/20/15 04:45, Florian Weimer wrote:
On 02/20/2015 10:30 AM, Andrew Haley wrote:
I doubt that such a thing is ever going to be safe. The idea that a
null pointer points to nothing is so hard-baked into the design of C
that you can't get away from it. Also, almost every C programmer and
esp
On 02/20/2015 11:06 AM, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memcpy pr
On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
> > H, Passing the additional option in user code would be one thing,
> > but what about library code? E.g., using memcpy (either explicitly or
> > implicitly for a structure copy
On 02/20/2015 12:43 PM, Jonathan Wakely wrote:
> On 20 February 2015 at 11:06, Florian Weimer wrote:
>> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>>> H, Passing the additional option in user code would be one thing,
>>> but what about library code? E.g., using memcpy (either explicitly
On 02/20/2015 10:30 AM, Andrew Haley wrote:
> I doubt that such a thing is ever going to be safe. The idea that a
> null pointer points to nothing is so hard-baked into the design of C
> that you can't get away from it. Also, almost every C programmer and
> especially library writer "knows" that
On 20 February 2015 at 11:06, Florian Weimer wrote:
> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>> H, Passing the additional option in user code would be one thing,
>> but what about library code? E.g., using memcpy (either explicitly or
>> implicitly for a structure copy)?
>
> The memc
On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
> H, Passing the additional option in user code would be one thing,
> but what about library code? E.g., using memcpy (either explicitly or
> implicitly for a structure copy)?
The memcpy problem isn't restricted to embedded architectures.
si
On 18/02/15 19:21, Jeff Prothero wrote:
> BTW, I'd also be curious to know what is regarded as engineering
> best practice for writing a value to address zero when this is
> architecturally required by the hardware platform at hand.
> Obviously one can do various things to obscure the process
> su
(Thanks to everyone for the helpful feedback!)
Daniel Gutson wrote:
> what about then two warnings (disabled by default), one intended to
> tell the user each time the compiler removes a conditional
> (-fdelete-null-pointer-checks)
> and another intended to tell the user each time the compiler
On 02/19/2015 03:09 PM, Jakub Jelinek wrote:
If you have hw where NULL is mapped and you know your code violates the
C/C++ standards by placing objects at that address, simply do use
the option that is designed for that purpose.
As I pointed out earlier, though, that won't help you if your pro
On Thu, Feb 19, 2015 at 06:16:05PM -0300, Daniel Gutson wrote:
> what about then two warnings (disabled by default), one intended to
> tell the user each time the compiler removes a conditional
> (-fdelete-null-pointer-checks)
> and another intended to tell the user each time the compiler adds a tr
On 20/02/2015 8:23 am, Joel Sherrill wrote:
On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
Jakub Jelinek wrote:
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths-dereference:
which
https://gcc.gnu
On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
> Jakub Jelinek wrote:
>> On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
>>> Starting with gcc 4.9, -O2 implicitly invokes
>>>
>>> -fisolate-erroneous-paths-dereference:
>>>
>>> which
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc/O
(Hi Sandra, so long!)
On Thu, Feb 19, 2015 at 5:56 PM, Sandra Loosemore
wrote:
> Jakub Jelinek wrote:
>>
>>
>> On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
>>>
>>> Starting with gcc 4.9, -O2 implicitly invokes
>>>
>>> -fisolate-erroneous-paths-dereference:
>>>
>>> which
>>>
Jakub Jelinek wrote:
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths-dereference:
which
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
documents as
Detect paths that trigger erroneo
On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero wrote:
>
> Starting with gcc 4.9, -O2 implicitly invokes
>
> -fisolate-erroneous-paths-dereference:
>
> which
>
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> documents as
>
> Detect paths that trigger erroneous or undefin
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
> Starting with gcc 4.9, -O2 implicitly invokes
>
> -fisolate-erroneous-paths-dereference:
>
> which
>
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> documents as
>
> Detect paths that trigger erroneous
32 matches
Mail list logo
