On Wed, Mar 4, 2015 at 12:38 AM, Jeff Law l...@redhat.com 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
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
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?
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
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 Wed, Feb 18, 2015 at
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 Wed, Feb 18, 2015 at
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 trade
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:
Starting with gcc 4.9,
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 memcpy
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 a
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.
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
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 or
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 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 problem
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
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/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
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
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
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/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
On Feb 20, 2015, at 12:01 PM, Jeff Law l...@redhat.com 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
On Feb 20, 2015, at 12:01 PM, Jeff Law l...@redhat.com 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
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
(Hi Sandra, so long!)
On Thu, Feb 19, 2015 at 5:56 PM, Sandra Loosemore
san...@codesourcery.com 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
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/Optimize-Options.html
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
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 trap
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
(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 Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero jprot...@altera.com 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
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 or
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 undefined behavior due to
dereferencing a null pointer. Isolate those paths
34 matches
Mail list logo
