: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
After fixing bug 118095, I discovered that `__builtin_has_attibute` needs to be
updated similarly to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #34 from Kees Cook ---
Hi! The proposed patch fixes the warning for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
Kees Cook changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
Kees Cook changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
--- Comment #4 from Kees Cook ---
(In reply to Andrew Pinski from comment #2)
> Take the address of one outside of the array is valid and well defined.
>
> That is:
> &p->array[3];
>
> is always valid and well defined.
This isn't about taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
--- Comment #1 from Kees Cook ---
And for reference, this is built with: -O2 -Wall -fstrict-flex-arrays=3
-fsanitize=bounds
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
--- Comment #4 from Kees Cook ---
I've added Martin to CC. :) Martin, you wrote this code originally; do you have
a moment to look at how this might best be solved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
--- Comment #3 from Kees Cook ---
(In reply to uecker from comment #1)
> I think you may also need to adapt get_attr_nonstring_decl
How do I walk "up" a tree to see if it is part of a multidimensional array? I
don't understand what is happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #22 from Kees Cook ---
On a related note, I need to be able to apply nonstring to arrays of char
arrays. See bug #118095.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
While this is legal:
char tag[4] __attribute__((nonstring));
this is not:
char tags[10][4] __attribute__((nonstring));
Given both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #21 from Kees Cook ---
Okay, now with tests and an updated truncation message. :)
Please see:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671714.html
(Hopefully I have managed to get coding and commit log style correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #19 from Kees Cook ---
Created attachment 59874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59874&action=edit
RFC for ignoring NUL byte with nonstring attribute
Here's an RFC patch for allowing the NUL char truncation when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug 69698 depends on bug 92589, which changed state.
Bug 92589 Summary: heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Kees Cook changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #7 from Kees Cook ---
Could "nonstring" be applied to string literals? (Like the "u" suffix idea, but
this would be more backward-compatible.) For example, from the example in
comment #1:
{ "BOOP", ... }
becomes:
{ "BOOT" __attr
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
The Linux kernel initializes many non-C-string char arrays with literals (e.g.
the ACPI tables have 4-character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #4 from Kees Cook ---
This feature is designed as a "security through obscurity" feature that has
real-world benefits to specialized high-security deployments where performance
is not a concern.
It is never expected to be compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
Kees Cook changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
--- Comment #5 from Kees Cook ---
(In reply to Kees Cook from comment #0)
> It should be be possible to trigger -fsanitize=bounds within
> __builtin_dynamoc_object_size() (which should have no side-effects).
Ugh typo. I meant "It should *not* b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
--- Comment #4 from Kees Cook ---
(In reply to Andrew Pinski from comment #1)
> I don't think so since &p->array[negative] is undefined behavior even inside
> a dynamic boz.
Without counted_by, that is true. With counted_by all out of bounds
ca
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
It should be be possible to trigger -fsanitize=bounds within
__builtin_dynamoc_object_size() (which should have no side-effects).
// CFLAGS
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
When counted_by is present in a structure, it means that the object must be a
singleton.
For example:
struct counted {
int counter;
int array[] __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #65 from Kees Cook ---
(In reply to Alejandro Colomar from comment #64)
> How about having two macros? One that works for non-attributed pointers,
> and other that works for attributed ones. And use the appropriate one for
> each o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #63 from Kees Cook ---
(In reply to Alejandro Colomar from comment #62)
> What's the value of returning NULL instead of just failing the compilation
> with an error?
It's so that the same allocator macros can be used for FAM structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #59 from Kees Cook ---
(In reply to Bill Wendling from comment #57)
> (In reply to Kees Cook from comment #47)
> > So, with the builtin being used within the allocator to set counter, now the
> > old code pattern still works (as coun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #55 from Kees Cook ---
(In reply to Alejandro Colomar from comment #49)
> For reading the counted_by value, that is, for reading the number of
> elements in the FAM, I'm implementing a __lengthof__ operator, which returns
> the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #47 from Kees Cook ---
Yes, the counter must be manually set until Linux minimum compiler versions are
raised to include counted_by support, but this is about making the transition
to using counted_by easier and less prone to bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #32 from Kees Cook ---
(In reply to qinzhao from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > Speaking of counted_by, I see support for it in c-family/ and c/, but not in
> > cp/ at all, what is the attribute suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #31 from Kees Cook ---
(In reply to Qing Zhao from comment #25)
> The source code need to be:
>
> If (__builtin_get_counted_by (P->FAM))
> __builtin_get_counted_by (P->FAM) = COUNT;
>
> Yes, I agree that this is good too for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #1 from Kees Cook ---
Matching Clang feature request:
https://github.com/llvm/llvm-project/issues/99774
mal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
With the wonderful addition of the 'counted_by' attribute and its wide roll-out
within the Linux kernel, we have found a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #8 from Kees Cook ---
The warning is about:
val = &sg->vals[index];
poc.c:20:20: warning: array subscript 4 is above array bounds of 'int[4]'
[-Warray-bounds=]
20 | val = &sg->vals[index];
|~~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #6 from Kees Cook ---
(In reply to qinzhao from comment #5)
> adding __attribute__ ((noreturn)) to the routine "warn" can eliminate the
> false positive warning.
But it does return... it's not an assert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #8 from Kees Cook ---
Clang bug: https://github.com/llvm/llvm-project/issues/84565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #7 from Kees Cook ---
There is still no way to use C99 flexible arrays in unions (or alone in
structs) without syntactic obfuscation. The extension that already allows
0-sized arrays in unions should be extended to cover C99 arrays. T
,
||kees at outflux dot net,
||ndesaulniers at google dot com,
||qing.zhao at oracle dot com
--- Comment #6 from Kees Cook ---
There is still no way to use C99 flexible arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #42 from Kees Cook ---
Exciting! Are you able to attach the latest patch? I'd love to try it out. I've
been testing Clang's version as well:
https://reviews.llvm.org/D148381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #3 from Kees Cook ---
Is there a viable path to a solution here? This seems to cause enough false
positives with -Warray-bounds that at least Linux can't enable the flag. I'd
really like to have it enabled, though, since it finds ple
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 54611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54611&action=edit
PoC for -Warray-bounds false positive
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #6 from Kees Cook ---
I really want to avoid the changes to sizeof() -- this will confuse a lot of
other things. Sizeof is expected to be a constant expression, for example.
I think the attribute is best since it avoids colliding wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #1 from Kees Cook ---
The corresponding Clang feature request is here:
https://github.com/llvm/llvm-project/issues/60928
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Frequently a structure containing a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Kees Cook changed:
What|Removed |Added
Attachment #54508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #1 from Kees Cook ---
The matching Clang bug is: https://github.com/llvm/llvm-project/issues/60926
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> Sorry, I forgot to include those details fully! Here's how I'm seeing it:
>
> $ gcc --version
> gcc (GCC) 13.0.0 20230105 (experimental)
> ...
> $ gcc -O2 -fno-strict-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #6 from Kees Cook ---
Sorry, I forgot to include those details fully! Here's how I'm seeing it:
$ gcc --version
gcc (GCC) 13.0.0 20230105 (experimental)
...
$ gcc -O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds -c -o /dev/n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
Attachment #54198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #2 from Kees Cook ---
Ugh, sorry. The PoC is bad -- the bounds check isn't present. Let me try to get
a another PoC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
CC||arnd at linaro dot org,
|
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 54198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54198&action=edit
reduced PoC
This seems similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #11 from Kees Cook ---
(In reply to Richard Biener from comment #10)
> I sofar refrained from doing this because of the large amount of fallout and
> followup changes and I think those are not warranted on the GCC 12 branch.
Totally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Kees Cook changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #9
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Hi,
Similar to this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106528
-Wmissing-indentation is blinded by comments:
int square(int num) {
if (num == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #6 from Kees Cook ---
(In reply to Richard Biener from comment #5)
> Should be fixed on trunk. Can you check on the original unreduced testcase?
Thanks! I've done test builds and can confirm these two false positives have
been elim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #41 from Kees Cook ---
(In reply to Bill Wendling from comment #40)
> The question then is if `-fstrict-flex-arrays=3' is used, what does a `[0]'
> at the end of a struct represent (assuming GCC no longer treats it as an
> FAM)?
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #34 from Kees Cook ---
-fstrict-flex-arrays=3 is still needed. (E.g. for proper FORTIFY coverage,
etc.) I don't have an opinion about the -W options, though.(In reply to James Y
Knight from comment #33)
> (In reply to qinzhao from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #21 from Kees Cook ---
(In reply to Martin Sebor from comment #20)
> Well, I just "asked" for such an option the same way you asked for
> -fstrict-flex-arrays in comment #3, because I believe it would be useful to
> make the BOS impr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #19 from Kees Cook ---
(In reply to Martin Sebor from comment #18)
> The zero size case exists (and is documented) solely as a substitute for
> flexible array members. Treating is as an ordinary array would disable that
> extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #17 from Kees Cook ---
(In reply to qinzhao from comment #16)
> additional work are needed in order to make this task complete:
>
> 1. add one more new gcc option:
>
> -fstrict-flex-arrays
>
> when it's on, only treat the followin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #13 from Kees Cook ---
Maybe the enum needs to also be expanded so that [0] can be distinguished from
[]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #11 from Kees Cook ---
and with a flex array to compare:
https://godbolt.org/z/s9nb4Y7q4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #10 from Kees Cook ---
Here's a slightly reworked example:
https://godbolt.org/z/EvehMax84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #9 from Kees Cook ---
Just to clarify, __builtin_dynamic_object_size() shouldn't have anything to do
with this. What's needed is something like -fstrict-flex-arrays so that all the
"trailing array is a flex array" assumptions can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #1 from Kees Cook ---
The Linux kernel has encountered at least two of these (seen as specifically
"array subscript 32", though the root cause may be causing many others:
../drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: arra
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 53010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53010&action=edit
test case minimized as much as possible
Some combination of things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #7 from Kees Cook ---
Right, perhaps I should rename this bug? The much more surprising thing is the
lack of warning about the uninit use. With or without -ftrivial-auto-var-init,
I'd want to have the diagnostic that a UB may have ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #2 from Kees Cook ---
https://godbolt.org/z/99Pdro9Te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #1 from Kees Cook ---
(Also this doesn't warn about y being used uninitialized.)
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
It looks like some pass is being run before the initializers are added:
int x (int z) {
int y;
if (z)
y = 10;
return y;
}
under "gcc -ftrivial-aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #4 from Kees Cook ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #4 from Kees Cook ---
(Ah, I knew this had been reported before. I found it now...)
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #2 from Kees Cook ---
As mentioned in a Linux kernel thread, isn't it possible to transform this:
switch (x) {
int y;
default:
y = x * 2;
return y;
}
into this:
{
int y;
switch (x) {
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #2 from Kees Cook ---
Note that this needs a struct attribute that will allow structs to be excluded
from the diagnostic (since the kernel needs to deal with legacy UAPI headers
forever).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #11 from Kees Cook ---
The trouble with "optimize" is that it just doesn't work. The kernel has banned
its use because it results in all other optimization options being forgotten
for the function in question.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
As done for powerpc (1b3254e4bbe82245421a55324bc8fe34a99c6e3c), aarch64
(cd0b2d361df82c848dc7e1c3078651bb0624c3c6), riscv
(c931e8d5a96463427040b0d11f9c4352ac22b2b0), and x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #9 from Kees Cook ---
(In reply to Jakub Jelinek from comment #8)
> So, instead (when building the kernel with sanitization) build with
> -fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
> the routines where you wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #7 from Kees Cook ---
The problem the kernel needs to solve is basically having our cake and eating
it too. :)
In _most_ situations, we want signed overflows to trap (i.e. get caught by
"-fsanitize=signed-integer-overflow").
In som
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Currently -fzero-call-used-regs will use a pattern of:
XOR regA,regA
MOV regA,regB
MOV regA,regC
...
RET
However, this introduces both a register ordering dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #3 from Kees Cook ---
Eww. That means _FORTIFY_SOURCE doesn't work correctly.
Can there please be a -fstrict-flex-arrays or something to turn off all the
heuristics so a code base can declare it only uses flex arrays for dynamic
tra
MED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51282&action=edit
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #5 from Kees Cook ---
Perhaps the best question to ask is "given an arbitrary argument, how can code
detect the remaining bytes of a member, including if the member contains a
flexible array?"
Because right now, this does not work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #4 from Kees Cook ---
It seems like this isn't about crossing field boundaries -- it's asking "how
large is this particular member?" and bos can't know the answer because there
is a flex-array.
Why would
__builtin_object_size(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #2 from Kees Cook ---
Created attachment 51280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51280&action=edit
Same PoC, but with malloc to provide non-unlimited bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #1 from Kees Cook ---
This is even more visible when the size IS known (via malloc hinting, for
example):
https://godbolt.org/z/4v5rKbhaf
MED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51279&action=edit
bos1 fails to
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51131&action=edit
memset collapsing breaks __builtin_obje
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
It would be nice to gain "-Wzero-length-array" so we can enforce this standard
in the Linux kernel once all conversions have moved struct to flexible array
members. Clang supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #8 from Kees Cook ---
Created attachment 48153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48153&action=edit
updated PoC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > (In reply to Kees Cook from comment #2)
> > > Is there anything to enforce a strict "only consider empty array size as
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
--- Comment #6 from Kees Cook ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Kees Cook from comment #2)
> > Is there anything to enforce a strict "only consider empty array size as
> > flexible array member" mode? This is an unfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
--- Comment #5 from Kees Cook ---
Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is very
close to what I was expecting to use:
https://bugs.llvm.org/show_bug.cgi?id=45295
That is close to what you're already suggesting.
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
1 - 100 of 128 matches
Mail list logo
