maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
1.5 KiB
C++
Raw Normal View History

[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
// RUN: %check_clang_tidy -std=c99 %s bugprone-implicit-widening-of-multiplication-result %t -- -- -target x86_64-unknown-unknown -x c
// RUN: %check_clang_tidy %s bugprone-implicit-widening-of-multiplication-result %t -- -- -target x86_64-unknown-unknown -x c++
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
_BitInt(64) t0(_BitInt(32) a, _BitInt(32) b) {
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
return a * b;
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
// CHECK-NOTES: :[[@LINE-1]]:10: warning: performing an implicit widening conversion to type '_BitInt(64)' of a multiplication performed in type '_BitInt(32)'
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
// CHECK-NOTES: :[[@LINE-2]]:10: note: make conversion explicit to silence this warning
// CHECK-NOTES: :[[@LINE-3]]:10: note: perform multiplication in a wider type
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
unsigned _BitInt(64) t1(_BitInt(32) a, _BitInt(32) b) {
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
return a * b;
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
// CHECK-NOTES: :[[@LINE-1]]:10: warning: performing an implicit widening conversion to type 'unsigned _BitInt(64)' of a multiplication performed in type '_BitInt(32)'
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
// CHECK-NOTES: :[[@LINE-2]]:10: note: make conversion explicit to silence this warning
// CHECK-NOTES: :[[@LINE-3]]:10: note: perform multiplication in a wider type
}
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
_BitInt(64) t2(unsigned _BitInt(32) a, unsigned _BitInt(32) b) {
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
return a * b;
Introduce _BitInt, deprecate _ExtInt WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-12-07 01:46:54 +08:00
// CHECK-NOTES: :[[@LINE-1]]:10: warning: performing an implicit widening conversion to type '_BitInt(64)' of a multiplication performed in type 'unsigned _BitInt(32)'
[clang-tidy] Add check for implicit widening of multiplication result Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * https://github.com/darktable-org/darktable/pull/7740 * https://github.com/darktable-org/darktable/pull/7419 * https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c * https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28 * https://github.com/darktable-org/darktable/pull/670 * https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583 and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
2021-04-14 02:21:19 +08:00
// CHECK-NOTES: :[[@LINE-2]]:10: note: make conversion explicit to silence this warning
// CHECK-NOTES: :[[@LINE-3]]:10: note: perform multiplication in a wider type
}