Improve -fno-strict-overflow description #694
Open
+35
−8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thomasnyman
force-pushed
the
fno-strict-overflow-improvement
branch
2 times, most recently
from
253f354 to
79d4dd9
Compare
|
|
||
| #### Synopsis | ||
|
|
||
| In C and C++ unsigned integers have long been defined as "wrapping around". However, for many years C and C++ have assumed that overflows do not occur in many other circumstances. Overflow when doing arithmetic with signed numbers is considered undefined by many versions of the official specifications, This approach also allows the compiler to assume strict pointer semantics: if adding an offset to a pointer does not produce a pointer to the same object. In practice, this means that important security checks written in the source code may be silently ignored when generating executable code. | ||
| In C and C++ unsigned integers have long been defined as "wrapping around". However, C and C++ compilers, by default, assume that overflows do not occur in other circumstances. Overflow when doing arithmetic with signed numbers is considered undefined the language specifications. This allows the compiler to assume strict pointer semantics: if adding an offset to a pointer does not produce a pointer to the same object, the addition is undefined. In practice, this means that important security checks written in the source code may be silently ignored when generating executable code. |
There was a problem hiding this comment.
"undefined the language" -> "undefined in the language"
There was a problem hiding this comment.
Fixed in e667c2f.
| @@ -937,15 +937,18 @@ There are normally no significant performance implications. Null pointer checks | |||
|
|
|||
| --- | |||
|
|
|||
| ### Integer overflow may occur | |||
| ### Define behavior for signed integer and pointer arithmetic overflows | |||
There was a problem hiding this comment.
Some of these don't define behavior, they complain about it, right?
There was a problem hiding this comment.
The options we cover here make signed-integers-arithmetic and pointer-arithmetic overflows either wrap-around or trap so I think it's justifiable to characterize that as defined behavior (as opposed to the default undefined behavior which allows for the optimizations that may case problems). We don't cover warnings here, so I'd be inclined to leave "defined" as it is.
|
|
||
| #### When not to use? | ||
|
|
||
| Standards-compliant C and C++ should not require any particular behavior for signed arithmetic overflows. Code which requires a specific behavior, such as a two's-complement representation becomes less portable in a very subtle way. Consequently, strictly standard-compliant C and C++ should not need the flags described in this section, and we recommend striving to write code that does not assume specific arithmetic overflow behavior. However, mistakes are inevitable and consequently we believe most code will benefit from `-fno-strict-overflow` or its alternatives. |
There was a problem hiding this comment.
Are you sure? Let's check. Newer standards may require twos-complement.
There was a problem hiding this comment.
Indeed you are right. In addition to C++20 which Gabriel pointed us to also C23 now requires two's complement representation for signed integers. Fixed in 203728f.
|
|
||
| #### Performance implications | ||
|
|
||
| Each of these options gives the compiler less freedom for optimizing the resulting machine code compared to the default `-fstrict-overflow` behavior. For example, under `-fstrict-overflow` semantics, expressions such as `i + 10 > i` will always be true for signed `i`, allowing the expression to be replaced at compile time with a constant value. As discussed above, if such expressions occur in condition checks the compiler may optimize away entire code paths when the expression can be evaluated at compile time. In contrast, under `-fno-strict-overflow` those expression must be evaluated at run-time in case of overflows that wrap around the value, thus preventing some optimizations. On the other hand, treating overflows as undefined behavior will only yield optimal behavior if the programmer can be certain the program will never inputs that cause overflows. |
There was a problem hiding this comment.
"will never inputs" -> "will never accept inputs"
There was a problem hiding this comment.
Fixed in 203728f.
Add -ftrapv and -fsanitize=signed-integer-overflow as alternative option Signed-off-by: Thomas Nyman <[email protected]>
Signed-off-by: Thomas Nyman <[email protected]>
thomasnyman
force-pushed
the
fno-strict-overflow-improvement
branch
from
fc2d0ff to
203728f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve
-fno-strict-overflowdescription and document changes in GCC 8.5.Add
-ftrapvand-fsanitize=signed-integer-overflowas alternative options.Add missing "When not to use?", "Performance implications", and "Other considerations subsections"
Fixes #685