Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Certainly, though, we are interested in producing better warnings to detect bad code of this kind, and I would expect (though I can't promise) that future GCC versions will warn in cases like this.
Posted Apr 16, 2008 19:16 UTC (Wed) by JoeBuck (subscriber, #2330)
GCC and pointer overflows
Posted Apr 18, 2008 5:48 UTC (Fri) by jd (guest, #26381)
In many cases with GCC, optimizations that are implied by something like -O2 or -O3 can be
specifically disabled, or additional optimizations can be specifically enabled.
If either case is true of the pointer arithmetic optimization in the newer GCCs, then this
would seem to be a better case to put. The "insecurity" is optional and only there because the
user has stipulated (implicitly or explicitly) that it should be.
Alternatvely, it might be argued that this shouldn't be in GCC proper (it's not a compiler
function, it's a validation function) but in a distinct module which scanned for likely range
violations and other cadidates for problems - something akin to splint or the stanford checker
but restricted to cases that can be reliably detected. You could then run it independently or
as part of the toolchain.
A third option would be to modify a source-to-source compiler like OpenIMPACT to alter tests
that would be optimized this way into a more correct form that doesn't need optimizing by GCC.
A fourth option is to have bounds-checking at runtime be implicit and require that it be
explicitly excluded at compile-time. Alternatively, since runtime bounds-checking is already
available, state that its exclusion is a voluntary statement on the part of a developer that
the validation of pointers is not wanted.
In other words, this seems a non-argument on any meaningful timescale. There are way too many
ways for the GCC developers, other members of the open source community or the developers of
potentially suspect code to eliminate the problem one way or another. If there is a potential
problem, it is a potential problem by mutual agreement.
Posted Apr 24, 2008 7:15 UTC (Thu) by eliezert (subscriber, #35757)
Of course it's best if we all stick to the standard, but people do make mistakes.
I think the simplest way to minimize this is to have an attribute marking the check as a
safty/sanity check so the compiler knows that:
1. It should not optimize this check out.
2. If it knows that this check will allways fail it can emit a warning.
3. If this check is assuming something improper it's better to fail the compilation and let
the coder look up the error somewhere, than to silently drop the test.
Posted Apr 24, 2008 20:39 UTC (Thu) by nix (subscriber, #2304)
You can't (yet) attach attributes to arbitrary expressions, though.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds