mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-30 12:56:07 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/test/CodeGen/object-size-flex-array.c

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

157 lines
4.0 KiB
C
Raw Normal View History

[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// RUN: %clang -target x86_64 -O2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-NO-STRICT %s
// RUN: %clang -fstrict-flex-arrays=0 -target x86_64 -O2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-0 %s
// RUN: %clang -fstrict-flex-arrays=1 -target x86_64 -O2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-1 %s
// RUN: %clang -fstrict-flex-arrays=2 -target x86_64 -O2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-2 %s
// RUN: %clang -fstrict-flex-arrays=3 -target x86_64 -O2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefixes=CHECK,CHECK-STRICT-3 %s
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
#define OBJECT_SIZE_BUILTIN __builtin_object_size
typedef struct {
float f;
double c[];
} foo_t;
typedef struct {
float f;
double c[0];
} foo0_t;
typedef struct {
float f;
double c[1];
} foo1_t;
typedef struct {
float f;
double c[2];
} foo2_t;
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @bar(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned bar(foo_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
// CHECK-STRICT-2: ret i32 -1
// CHECK-STRICT-3: ret i32 -1
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @bar0(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned bar0(foo0_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
// CHECK-STRICT-2: ret i32 -1
// CHECK-STRICT-3: ret i32 0
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @bar1(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned bar1(foo1_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// CHECK-STRICT-2: ret i32 8
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-STRICT-3: ret i32 8
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @bar2(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned bar2(foo2_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// CHECK-STRICT-1: ret i32 16
// CHECK-STRICT-2: ret i32 16
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-STRICT-3: ret i32 16
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
#define DYNAMIC_OBJECT_SIZE_BUILTIN __builtin_dynamic_object_size
// CHECK-LABEL: @dyn_bar(
unsigned dyn_bar(foo_t *f) {
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
// CHECK-STRICT-2: ret i32 -1
// CHECK-STRICT-3: ret i32 -1
return DYNAMIC_OBJECT_SIZE_BUILTIN(f->c, 1);
}
// CHECK-LABEL: @dyn_bar0(
unsigned dyn_bar0(foo0_t *f) {
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
// CHECK-STRICT-2: ret i32 -1
// CHECK-STRICT-3: ret i32 0
return DYNAMIC_OBJECT_SIZE_BUILTIN(f->c, 1);
}
// CHECK-LABEL: @dyn_bar1(
unsigned dyn_bar1(foo1_t *f) {
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 -1
// CHECK-STRICT-2: ret i32 8
// CHECK-STRICT-3: ret i32 8
return DYNAMIC_OBJECT_SIZE_BUILTIN(f->c, 1);
}
// CHECK-LABEL: @dyn_bar2(
unsigned dyn_bar2(foo2_t *f) {
// CHECK-NO-STRICT: ret i32 -1
// CHECK-STRICT-0: ret i32 -1
// CHECK-STRICT-1: ret i32 16
// CHECK-STRICT-2: ret i32 16
// CHECK-STRICT-3: ret i32 16
return DYNAMIC_OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// Also checks for non-trailing flex-array like members
typedef struct {
double c[0];
float f;
} foofoo0_t;
typedef struct {
double c[1];
float f;
} foofoo1_t;
typedef struct {
double c[2];
float f;
} foofoo2_t;
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @babar0(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned babar0(foofoo0_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 0
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// CHECK-STRICT-0: ret i32 0
// CHECK-STRICT-1: ret i32 0
// CHECK-STRICT-2: ret i32 0
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-STRICT-3: ret i32 0
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @babar1(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned babar1(foofoo1_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 8
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// CHECK-STRICT-0: ret i32 8
// CHECK-STRICT-1: ret i32 8
// CHECK-STRICT-2: ret i32 8
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-STRICT-3: ret i32 8
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
[clang] cleanup -fstrict-flex-arrays implementation This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining comments. It also considers union with a single zero-length array field as FAM for each value of -fstrict-flex-arrays. Differential Revision: https://reviews.llvm.org/D132944
2022-08-30 16:49:53 +02:00
// CHECK-LABEL: @babar2(
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
unsigned babar2(foofoo2_t *f) {
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-NO-STRICT: ret i32 16
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
// CHECK-STRICT-0: ret i32 16
// CHECK-STRICT-1: ret i32 16
// CHECK-STRICT-2: ret i32 16
[clang] Implement -fstrict-flex-arrays=3 The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays. No number, including 0, is allowed in the FAM. In the cases where a "0" is used, the resulting size is the same as if a zero-sized object were substituted. This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel, among other reasons. So while the only reason for specifying a zero-length array at the end of a structure is for specify a FAM, treating it as such will cause _FORTIFY_SOURCE not to work correctly; __builtin_object_size will report -1 instead of 0 for a destination buffer size to keep any kernel internals from using the deprecated members as fake FAMs. For example: struct broken { int foo; int fake_fam[0]; struct something oops; }; There have been bugs where the above struct was created because "oops" was added after "fake_fam" by someone not realizing. Under __FORTIFY_SOURCE, doing: memcpy(p->fake_fam, src, len); raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1 and may stomp on "oops." Omitting a warning when using the (invalid) zero-length array is how GCC treats -fstrict-flex-arrays=3. A warning in that situation is likely an irritant, because requesting this option level is explicitly requesting this behavior. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Differential Revision: https://reviews.llvm.org/D134902
2022-10-20 16:10:31 -07:00
// CHECK-STRICT-3: ret i32 16
[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays Some code [0] consider that trailing arrays are flexible, whatever their size. Support for these legacy code has been introduced in f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of __builtin_object_size and __builtin_dynamic_object_size in some legit cases. Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is desirable. n = 0: current behavior, any trailing array member is a flexible array. The default. n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member n = 2: any trailing array member of undefined or 0 size is a flexible array member This takes into account two specificities of clang: array bounds as macro id disqualify FAM, as well as non standard layout. Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
2022-06-28 11:01:55 +02:00
return OBJECT_SIZE_BUILTIN(f->c, 1);
}
Reference in New Issue Copy Permalink