[Bug c/119481] -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 --- Comment #9 from Alejandro Colomar --- BTW, maybe the example I presented wasn't explicit enough about the dangers of this. Here's an example of a program which results in a bug, with no diagnostics. alx@devuan:~/tmp$ cat ml.c | grep -Tn ^

[Bug c/119481] -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 --- Comment #8 from Alejandro Colomar --- (In reply to Jonathan Wakely from comment #7) > (In reply to Alejandro Colomar from comment #6) > > But maybe I should say (part of) this extension is quite dangerous, > > regardless of it violating the

[Bug c/119481] -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 --- Comment #6 from Alejandro Colomar --- (In reply to Eric Botcazou from comment #5) > What's the point in saying that extensions violate a standard, since they > are designed for this? There are extensions that define something not defined by

[Bug c/119481] -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 Alejandro Colomar changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug c/119481] -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 --- Comment #1 from Alejandro Colomar --- alx@devuan:~/tmp$ gcc -Wall -Wextra -fplan9-extensions -Wpedantic cast.c alx@devuan:~/tmp$ -Wpedantic still doesn't say anything. It should. And this should even go into -Wextra or -Wall.

[Bug c/119481] New: -fplan9-extensions violates the C standard (6.3.3.3p7)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481 Bug ID: 119481 Summary: -fplan9-extensions violates the C standard (6.3.3.3p7) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug c/119476] New: [-Wdiscarded-qualifiers] False negative with -fplan9-extensions inheritance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119476 Bug ID: 119476 Summary: [-Wdiscarded-qualifiers] False negative with -fplan9-extensions inheritance Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: no

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 Alejandro Colomar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVA

[Bug analyzer/119104] Regression in memcpy(3) if [[gnu::nonnull_if_nonzero]] is used instead of [[gnu::nonnull]]; unclear docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104 --- Comment #7 from Alejandro Colomar --- alx@devuan:~/tmp$ cat nninz.c | grep -Tn ^ 1:#include 2: 3:extern int any; 4: 5:[[gnu::nonnull]]

[Bug c/119251] New diagnostic: -Wcompound-literal-address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251 --- Comment #10 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #8) > In that case the warning should be also restricted to the case when ({ comes > from macro expansion and the compound literal from macro argument (not sure >

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #20 from Alejandro Colomar --- (In reply to Kang-Che Sung from comment #19) > I personally don't like when there is an "oligopoly" on the compilers (C and > C++ should have a less centralized ecosystem than Java or Python), but this

[Bug c/119251] New diagnostic: -Wcompound-literal-address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251 --- Comment #6 from Alejandro Colomar --- (In reply to uecker from comment #5) > Maybe a more targeted warning would make sense, e.g. taking the address of a > compound literal inside ({ }). Maybe even checking whether it escapes? > And/or onl

[Bug c/119251] New diagnostic: -Wcompound-literal-address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251 --- Comment #3 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #1) > How is compound literal different from any other automatic variable? > And of course taking the address of compound literal when used in scope is > just fine

[Bug c/119251] New diagnostic: -Wcompound-literal-address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251 --- Comment #4 from Alejandro Colomar --- I understand that program rely on this. I don't intend this diagnostic to be in -Wextra (at least not for now). I just want to have it available, so that I can enable it for myself.

[Bug c/119251] New: New diagnostic: -Wcompound-literal-address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119251 Bug ID: 119251 Summary: New diagnostic: -Wcompound-literal-address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #17 from Alejandro Colomar --- (In reply to Kang-Che Sung from comment #16) > (In reply to Alejandro Colomar from comment #13) > > Not really unimportant. Every time someone writes one of these in a > > project, you need to make sur

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #14 from Alejandro Colomar --- (In reply to Joseph S. Myers from comment #11) > The ISO Code of Ethics and Conduct includes "We abide by the policies of ISO > and embrace the concepts of compromise and consensus building, and notably

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #13 from Alejandro Colomar --- (In reply to Kang-Che Sung from comment #12) > As the width of these types can be retrieved via the `sizeof(T) * CHAR_BIT` > fallback, I said the `_Widthof` operator on these types is not a > "necessity

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #10 from Alejandro Colomar --- (In reply to Kang-Che Sung from comment #9) > Is there still room to make comments about the proposal? Yes. This will not be voted for inclusion in the standard until around 2025-09, and the proposal

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #8 from Alejandro Colomar --- (In reply to Joseph S. Myers from comment #7) > In particular, the subtle issues around semantics for bit-field expression > operands (see N2958) are definitely something that should be discussed in a >

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #5 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > Suspended until this is approved by the C committee for the names. On the other hand, my experience with the C Committee is that they aren't the best place

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #4 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #3) > No comments from me; but I suspect others will but they are more likely > address it via WG14 rather than here. Thanks! I've already requested an N number

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #2 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > Suspended until this is approved by the C committee for the names. Any comments on the feature itself? It would be interesting to present a paper that has

[Bug c/119170] New: Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 Bug ID: 119170 Summary: Add operators _Widthof, _Minof, _Maxof Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119169 --- Comment #4 from Alejandro Colomar --- (In reply to Sam James from comment #2) > I suspect your GCC is too old and lacks r15-7682-g206cb6c10589be. Please > always include the version in reports. Hmmm, that's good news. Thanks! And sorry!

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119169 --- Comment #1 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #0) > The most basic code that should trigger a -Wanalyzer-possible-null-argument > diagnostic with [[gnu::nonnull]], doesn't. Here I obviously meant [[gnu::n

[Bug analyzer/119169] New: [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119169 Bug ID: 119169 Summary: [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression Product: gcc Ver

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #29 from Alejandro Colomar --- Hi Kees, (In reply to GCC Commits from comment #28) > The master branch has been updated by Jakub Jelinek : > > https://gcc.gnu.org/g:622968990beee7499e951590258363545b4a3b57 I guess I should have re

[Bug analyzer/119104] Regression in memcpy(3) if [[gnu::nonnull_if_nonzero]] is used instead of [[gnu::nonnull]]; unclear docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104 --- Comment #6 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #5) > They should. It is more important not to force UB on cases where there is > no harm (i.e. runtime memcpy (NULL, NULL, 0) and similar) than to get some > ext

[Bug analyzer/119104] Regression in memcpy(3) if [[gnu::nonnull_if_nonzero]] is used instead of [[gnu::nonnull]]; unclear docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104 --- Comment #4 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #3) > The analyzer will be hopefully improved for GCC 16, there was just a minimal > support added so that the analyzer tests didn't regress. > The normal -Wnonnul

[Bug c/119104] Unclear documentation for [[gnu::nonnull_if_nonzero]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104 --- Comment #2 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > Non zero and zero are runtime values of here. Rather than compile > characteristics of that argument. > > Maybe just: > If the runtume value of the integral

[Bug c/119104] New: Unclear documentation for [[gnu::nonnull_if_nonzero]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104 Bug ID: 119104 Summary: Unclear documentation for [[gnu::nonnull_if_nonzero]] Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #6 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #5) > (In reply to Alejandro Colomar from comment #3) > > Not yet. I commented it yesterday with Aaron Ballman during a break in the > > C Committee meeting, and

[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #4 from Alejandro Colomar --- I can still show the paper to other members of the C Committee, though, to see their opinion. But I prefer not proposing it officially.

[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #3 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #2) > Plus why not just use casts? They tend to be dangerous when misplaced or when their type is accidentally wrong. For example, the following could be diagno

[Bug c/119068] Should -Wwrite-strings be renamed to -fwrite-strings?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119068 --- Comment #1 from Alejandro Colomar --- BTW, now that I report this, I remember myself always having doubts if -Wwrite-strings makes the string literals writable, or what. The name was misleading, so maybe if we move it into an -f flag, we co

[Bug c/119058] New: wbN: A suffix for specifying the width of a bit-precise integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 Bug ID: 119058 Summary: wbN: A suffix for specifying the width of a bit-precise integer literal Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c/17654] Pointless warning on incompatible pointer types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17654 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment #1

[Bug c/119068] New: Should -Wwrite-strings be renamed to -fwrite-strings?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119068 Bug ID: 119068 Summary: Should -Wwrite-strings be renamed to -fwrite-strings? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug c/17654] Pointless warning on incompatible pointer types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17654 --- Comment #12 from Alejandro Colomar --- Clang bug:

[Bug c/119041] New: Please diagnose on _Noreturn calls within [[gnu::const]], [[gnu::pure]], [[reproducible]], [[unsequenced]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119041 Bug ID: 119041 Summary: Please diagnose on _Noreturn calls within [[gnu::const]], [[gnu::pure]], [[reproducible]], [[unsequenced]] Product: gcc Version: 14.2.0

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #18 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #13) > (In reply to Paul Eggert from comment #12) > > Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short' > > (yes that'd be really weir

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #17 from Alejandro Colomar --- (In reply to Eric Gallager from comment #16) > I'd just like to restate my preference for using separate named options > instead of numerical warning levels. Brainstorming some ideas for potential > nam

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #13 from Alejandro Colomar --- (In reply to Paul Eggert from comment #12) > Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short' > (yes that'd be really weird for time_t, but ISO C and POSIX allow it and > I try

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #10 from Alejandro Colomar --- (In reply to Vincent Lefèvre from comment #9) > (In reply to Paul Eggert from comment #8) > > (In reply to Jakub Jelinek from comment #4) > > > just use ~(time_t)0 or similar. > > That has a cast, and p

[Bug c/119019] New: -Wshadow false negative for function parameter (used as array length expression) shadowing a global variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119019 Bug ID: 119019 Summary: -Wshadow false negative for function parameter (used as array length expression) shadowing a global variable Product: gcc Version: 14.2.0

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #7 from Alejandro Colomar --- (In reply to Jonathan Wakely from comment #6) > Not warning at all for a literal -1 seems reasonable to me. It's such a > common idiom to compare to -1 for error checks. > > So suppress the warning only

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #5 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #4) > (In reply to Alejandro Colomar from comment #3) > > unsigned long == -1 does The Right Thing(tm). The -1 is first > > sign-extended, and afterwards converte

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #3 from Alejandro Colomar --- (In reply to Richard Biener from comment #2) > Your point that unsigned long == -1 vs. unsigned long == -1u is not the same > is a very good point to continue diagnosing this. But the bug is actually in

[Bug c/119011] -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #1 from Alejandro Colomar --- Or maybe we can just make -Wsign-compare not warn on that, without adding levels at all.

[Bug c/119011] New: -Wsign-compare: Split it into several levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 Bug ID: 119011 Summary: -Wsign-compare: Split it into several levels Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/119005] -Wstrict-overflow=3 false positive with static variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005 --- Comment #3 from Alejandro Colomar --- Hmmm, thinking twice, I guess it is not a false positive. I can rewrite to something similar, which avoids the overflow, and avoids the diagnostic: alx@debian:~/tmp$ cat foo.c #include int f(void) {

[Bug c/119005] -Wstrict-overflow=3 false positive with static variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005 Alejandro Colomar changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Alejandro

[Bug c/119005] New: -Wstrict-overflow=3 false positive with static variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005 Bug ID: 119005 Summary: -Wstrict-overflow=3 false positive with static variable Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Pri

[Bug c/119004] New: Inconsistent set of flags to trigger -Wstrict-overflow diagnostics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119004 Bug ID: 119004 Summary: Inconsistent set of flags to trigger -Wstrict-overflow diagnostics Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/118588] -Wmaybe-uninitialized false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118588 --- Comment #3 from Alejandro Colomar --- Okay, I can live with it, I guess. I was just experimenting with these warnings, and don't have any real code where this is a false positive. I guess in actual code I would make the function get a non-

[Bug c/118588] New: -Wmaybe-uninitialized false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118588 Bug ID: 118588 Summary: -Wmaybe-uninitialized false positive Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/118585] no diagnostics with [[gnu::malloc(free)]] and p++ if a function takes the pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118585 --- Comment #1 from Alejandro Colomar --- If I change foo() --which takes void*-- by bar() --which takes const void*--, then the warnings are triggered. I guess the analyzer thinks foo() might correctly free(p) inside, but that assumption would

[Bug c/118585] New: no diagnostics with [[gnu::malloc(free)]] and p++ if a function takes the pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118585 Bug ID: 118585 Summary: no diagnostics with [[gnu::malloc(free)]] and p++ if a function takes the pointer Product: gcc Version: 15.0 Status: UNCONFIRMED Severi

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #8 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #7) > (In reply to Alejandro Colomar from comment #6) > > (In reply to David Malcolm from comment #5) > > > Thanks for filing this report. > > > > You're welc

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #7 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #6) > (In reply to David Malcolm from comment #5) > > Thanks for filing this report. > > You're welcome! :-) > > > > > There are (at least) three -fanalyze

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #6 from Alejandro Colomar --- (In reply to David Malcolm from comment #5) > Thanks for filing this report. You're welcome! :-) > > There are (at least) three -fanalyzer issues here: > > (a) false positive about leak of 'my_strdu

[Bug analyzer/118498] not diagnostic a leak with analyzer and malloc attribute with free filled in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498 --- Comment #7 from Alejandro Colomar --- (In reply to David Malcolm from comment #6) > -fanalyzer deliberately doesn't warn about memory leaks within "main": > https://godbolt.org/z/94ch4T1Ke > given that once you exit main, leaks don't matte

[Bug preprocessor/118519] Escaped line breaks in the middle of a token

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519 --- Comment #2 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #1) > Why? A lot of programs use quite long identifiers and in projects which use > strict line length restrictions it is still useful. Hmmm, can you please shar

[Bug c/118519] New: Escaped line breaks in the middle of a token

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519 Bug ID: 118519 Summary: Escaped line breaks in the middle of a token Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #4 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > I think this need analyzer to handle really. We get a -Wfree-nonheap-object if I change the strsep(3) call by s++. I think we should treat any call that ge

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #3 from Alejandro Colomar --- (In reply to Sam James from comment #2) > With -O0/-O1, we do get -Wanalyzer-malloc-leak. It gets lost with >= -O2 > unless we use noinine on my_strdup. Not sure if that's another case of > PR100717 and

[Bug c/118500] New: no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 Bug ID: 118500 Summary: no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug analyzer/118498] not diagnostic a leak with analyzer and malloc attribute with free filled in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498 --- Comment #4 from Alejandro Colomar --- (In reply to Sam James from comment #1) > Where's the deallocation? There's not. I expected that(In reply to Andrew Pinski from comment #2) > (In reply to Sam James from comment #1) > > Where's the dea

[Bug c/118498] New: -Wmismatched-dealloc false negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498 Bug ID: 118498 Summary: -Wmismatched-dealloc false negative Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/118095] nonstring attribute cannot be applied to array of char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment #

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #23 from Alejandro Colomar --- If the attribute could be applied to a type, then you could apply it this way: alx@debian:~/tmp/gcc$ cat nonstring.c typeof(__attribute__((nonstring)) char [4]) tags[10]; alx@debian:~/tmp/gcc$ gcc -Wa

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #20 from Alejandro Colomar --- Hi Kees, (In reply to Kees Cook from comment #19) > Created attachment 59874 [details] > RFC for ignoring NUL byte with nonstring attribute > > Here's an RFC patch for allowing the NUL char truncation

[Bug c/118044] -Wvla-parameter: False positive with [[gnu::access(wo, n)]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 --- Comment #2 from Alejandro Colomar --- Hmmm, interesting. Thanks!

[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 --- Comment #3 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > /* The two specs designate different size arguments. It's okay > for the explicit spec to specify a size where none is provided >

[Bug c/118044] New: -Wvla-parameter: False positive with [[gnu::access(wo, n)]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 Bug ID: 118044 Summary: -Wvla-parameter: False positive with [[gnu::access(wo, n)]] Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/118043] New: -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 Bug ID: 118043 Summary: -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #17 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #15) > I think the current behavior is correct, noipa implies the function boundary > is an optimization barrier for the compiler, while inline is the exact > opp

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #16 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #13) > We have been warning about noinline and inline since the noinline attribute > was added back in r0-37987-g9162542e3d0cd2 . > > When noipa was added (r8-22

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #12 from Alejandro Colomar --- (In reply to Sam James from comment #11) > Perhaps it makes sense to only set these when building under a static > analyser then. GCC does itself have some static analysing features via compiler diagno

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #10 from Alejandro Colomar --- (In reply to Sam James from comment #9) > If they're internals, building the library with LTO and correct visibility > annotations should handle that for you if you mean "I want inlining > internally, b

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #8 from Alejandro Colomar --- (In reply to Sam James from comment #7) > (In reply to Alejandro Colomar from comment #6) > > (In reply to Sam James from comment #3) > > > The boundary doesn't exist if it's being inlined. > > > > [[gn

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #6 from Alejandro Colomar --- (In reply to Sam James from comment #3) > The boundary doesn't exist if it's being inlined. [[gnu::noipa]] is stronger and prevents any inlining (it's basically telling the compiler to ignore 'inline').

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #4 from Alejandro Colomar --- Maaaybe I could do the following instead, I guess. I will probably do it anyway, for compatibility with old GCC versions. I little bit more cpp(1), but that's okay-ish too, I guess. // : #if (FOO_INT

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #2 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > So noipa implies noinline. Hmmm, I thought it could be considered something like , where you're showing

[Bug c/118005] New: Incorrect diagnostic combining [[gnu::noipa]] and inline

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 Bug ID: 118005 Summary: Incorrect diagnostic combining [[gnu::noipa]] and inline Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Pr

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #10 from Alejandro Colomar --- Do we warn about enum/_Bool (PR112556) with this? My computer with which I work with GCC is having a hardware failure and I can't use it until 3 weeks from now when a new piece arrives.

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 --- Comment #3 from Alejandro Colomar --- (In reply to Xi Ruoyao from comment #2) > No, it *is* initializing a pointer. You cannot initialize a struct with 0. > Instead the initializer is considered "flattened" in C. > > For example: > > str

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 --- Comment #1 from Alejandro Colomar --- On the other hand, it would be interesting to have a diagnostic that helps switching from {0} to {}.

[Bug c/117610] New: -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 Bug ID: 117610 Summary: -Wzero-as-null-pointer-constant false positive with {0} Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Prior

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #8 from Alejandro Colomar --- Several years don't buy us much. I think having it for 1 release will already make it better. Further than 1 release gives us not much value; especially if there's no release notes that say that it wil

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #6 from Alejandro Colomar --- Hmm, okay, Wextra as a first step makes sense. How about one release in Wextra, and then move it to Wall? As for ISO C, I'm not sure if ISO is a good place to start the deprecation. I don't like ISO i

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #4 from Alejandro Colomar --- Since I would like to officially deprecate 0 as a null pointer constant, it would be good if we put it in -Wall. Does it make sense?

[Bug middle-end/108036] [12/13/14/15 Regression] Spurious warning for zero-sized array parameters to a function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Alejandro Colomar changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comme

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #12 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #11) > (In reply to Alejandro Colomar from comment #9) > > > > I think it's simpler to have -Wc++-compat warn about any uses of > > [[gnu::nonstring]] at all, si

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #10 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #9) > (In reply to Kees Cook from comment #7) > > Could "nonstring" be applied to string literals? (Like the "u" suffix idea, > > but this would be more backw

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #9 from Alejandro Colomar --- (In reply to Kees Cook from comment #7) > 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 com

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #6 from Alejandro Colomar --- (In reply to Jonathan Wakely from comment #5) > (In reply to Alejandro Colomar from comment #4) > > As for C++, maybe such an initialization should be acceptable as a GNU > > extension. > > Please, no.

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #4 from Alejandro Colomar --- +1 The proposal makes sense to me. I had originally proposed something such as char x[3] = "foo"u; for marking that as a non-string. But that was because I didn't know about [[gnu::nonstring]].

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #7 from Alejandro Colomar --- See also:

  1   2   >