mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-23 22:16:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/test/Analysis/flexible-array-members.c

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

167 lines
6.0 KiB
C
Raw Permalink Normal View History

[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// -fstrict-flex-arrays=2 means that only undefined or zero element arrays are considered as FAMs.
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c90 \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c99 \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c11 \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c17 \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++98 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++03 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++11 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++14 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
[analyzer] Consider single-elem arrays as FAMs by default According to my measurement in https://reviews.llvm.org/D108230#3933232, it seems like there is no drawback to enabling this analyzer-config by default. Actually, enabling this by default would make it consistent with the codegen of clang, which according to `-fstrict-flex-arrays`, assumes by default that all trailing arrays could be FAMs, let them be of size undefined, zero, one, or anything else. Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate the analyzer-config FAM option in favor of that flag. That way, CSA will always be in sync with what the codegen will think of FAMs. So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0, CSA will also make sure that only arrays of the right size will be considered as FAMs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138657
2022-11-25 10:24:56 +01:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++17 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -fstrict-flex-arrays=2
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// By default, -fstrict-flex-arrays=0, which means that even single element arrays are considered as FAMs.
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c17 \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -DSINGLE_ELEMENT_FAMS
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
// RUN: %clang_analyze_cc1 -triple x86_64-linux-gnu -analyzer-checker=core,unix,debug.ExprInspection %s -verify -std=c++17 -x c++ \
[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays instead By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-25 10:24:56 +01:00
// RUN: -DSINGLE_ELEMENT_FAMS
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
typedef __typeof(sizeof(int)) size_t;
size_t clang_analyzer_getExtent(void *);
void clang_analyzer_dump(size_t);
void *alloca(size_t size);
void *malloc(size_t size);
void free(void *ptr);
A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the ninth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-13 08:02:46 -05:00
void test_incomplete_array_fam(void) {
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
typedef struct FAM {
char c;
int data[];
} FAM;
FAM fam;
clang_analyzer_dump(clang_analyzer_getExtent(&fam));
clang_analyzer_dump(clang_analyzer_getExtent(fam.data));
// expected-warning@-2 {{4 S64b}}
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{0 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
FAM *p = (FAM *)alloca(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(p));
clang_analyzer_dump(clang_analyzer_getExtent(p->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{4 S64b}}
// expected-warning@-2 {{0 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
FAM *q = (FAM *)malloc(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(q));
clang_analyzer_dump(clang_analyzer_getExtent(q->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{4 S64b}}
// expected-warning@-2 {{0 S64b}}
free(q);
q = (FAM *)malloc(sizeof(FAM) + sizeof(int) * 2);
clang_analyzer_dump(clang_analyzer_getExtent(q));
clang_analyzer_dump(clang_analyzer_getExtent(q->data));
// expected-warning@-2 {{12 S64b}}
// expected-warning@-2 {{8 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
free(q);
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
typedef struct __attribute__((packed)) {
char c;
int data[];
} PackedFAM;
PackedFAM *t = (PackedFAM *)malloc(sizeof(PackedFAM) + sizeof(int) * 2);
clang_analyzer_dump(clang_analyzer_getExtent(t));
clang_analyzer_dump(clang_analyzer_getExtent(t->data));
// expected-warning@-2 {{9 S64b}}
// expected-warning@-2 {{8 S64b}}
free(t);
}
void test_too_small_base(void) {
typedef struct FAM {
long c;
int data[];
} FAM;
short s = 0;
FAM *p = (FAM *) &s;
clang_analyzer_dump(clang_analyzer_getExtent(p));
clang_analyzer_dump(clang_analyzer_getExtent(p->data));
// expected-warning@-2 {{2 S64b}}
// expected-warning@-2 {{-6 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
}
A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the ninth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-13 08:02:46 -05:00
void test_zero_length_array_fam(void) {
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
typedef struct FAM {
char c;
int data[0];
} FAM;
FAM fam;
clang_analyzer_dump(clang_analyzer_getExtent(&fam));
clang_analyzer_dump(clang_analyzer_getExtent(fam.data));
// expected-warning@-2 {{4 S64b}}
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{0 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
FAM *p = (FAM *)alloca(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(p));
clang_analyzer_dump(clang_analyzer_getExtent(p->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{4 S64b}}
// expected-warning@-2 {{0 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
FAM *q = (FAM *)malloc(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(q));
clang_analyzer_dump(clang_analyzer_getExtent(q->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{4 S64b}}
// expected-warning@-2 {{0 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
free(q);
}
A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the ninth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-13 08:02:46 -05:00
void test_single_element_array_possible_fam(void) {
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
typedef struct FAM {
char c;
int data[1];
} FAM;
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
#ifdef SINGLE_ELEMENT_FAMS
FAM likely_fam;
clang_analyzer_dump(clang_analyzer_getExtent(&likely_fam));
clang_analyzer_dump(clang_analyzer_getExtent(likely_fam.data));
// expected-warning@-2 {{8 S64b}}
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{4 S64b}}
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
FAM *p = (FAM *)alloca(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(p));
clang_analyzer_dump(clang_analyzer_getExtent(p->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{8 S64b}}
// expected-warning@-2 {{4 S64b}}
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
FAM *q = (FAM *)malloc(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(q));
clang_analyzer_dump(clang_analyzer_getExtent(q->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{8 S64b}}
// expected-warning@-2 {{4 S64b}}
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
free(q);
#else
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
FAM likely_fam;
clang_analyzer_dump(clang_analyzer_getExtent(&likely_fam));
clang_analyzer_dump(clang_analyzer_getExtent(likely_fam.data));
// expected-warning@-2 {{8 S64b}}
// expected-warning@-2 {{4 S64b}}
FAM *p = (FAM *)alloca(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(p));
clang_analyzer_dump(clang_analyzer_getExtent(p->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{8 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
// expected-warning@-2 {{4 S64b}}
FAM *q = (FAM *)malloc(sizeof(FAM));
clang_analyzer_dump(clang_analyzer_getExtent(q));
clang_analyzer_dump(clang_analyzer_getExtent(q->data));
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499
2023-08-22 18:15:00 +08:00
// expected-warning@-2 {{8 S64b}}
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
// expected-warning@-2 {{4 S64b}}
free(q);
[analyzer] Ignore single element arrays in getStaticSize() conditionally Quoting https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html: > In the absence of the zero-length array extension, in ISO C90 the contents > array in the example above would typically be declared to have a single > element. We should not assume that the size of the //flexible array member// field has a single element, because in some cases they use it as a fallback for not having the //zero-length array// language extension. In this case, the analyzer should return `Unknown` as the extent of the field instead. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D108230
2021-09-04 10:19:57 +02:00
#endif
Revert "Revert "[analyzer] Ignore IncompleteArrayTypes in getStaticSize() for FAMs"" This reverts commit df1f4e0cc6ec9a734aae41ffd48ee8b2007fcabb. Now the test case explicitly specifies the target triple. I decided to use x86_64 for that matter, to have a fixed bitwidth for `size_t`. Aside from that, relanding the original changes of: https://reviews.llvm.org/D105184
2021-08-25 16:47:13 +02:00
}
Reference in New Issue Copy Permalink