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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds