https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120455
--- Comment #7 from lavr at ncbi dot nlm.nih.gov ---
> it would be an *extension*.
An extension to what? Other compilers allow the const qualifier conversion,
and it's logically correct (and it is correct in C++, like shown).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68612
--- Comment #9 from lavr at ncbi dot nlm.nih.gov ---
GCC14 is breaking builds now, because the warning has been promoted to error,
with this problem still unresolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120455
--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
Wow, it's a ten year old problem now is breaking the builds because of the
warning to error promotion! The latter should not have been done with the
outstanding problem like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120455
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
* was prompted
was promoted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120455
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
sja...@gcc.gnu.org:
Strictly speaking, returning a pointer is not the same as taking it in by
adding const qualifiers. In my code example, "func()" can't change anything
pointed to by "str",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120455
Bug ID: 120455
Summary: char** and -Wincompatible-pointer-types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
CC||lavr at ncbi dot nlm.nih.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
lavr at ncbi dot nlm.nih.gov changed:
What|Removed |Added
CC||lavr at ncbi dot nlm.nih.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
Also, the standard seems to mention that flush() is an "unformatted output
function", meaning it is supposed to build and check a sentry object (which in
case of a bad stream, would fail, so it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Indeed, it does not. But the reason the endl manipulator is there, is to flush
_after_ '\n'. If the stream has gone bad in between, it is the gray area, but
for the output device (the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
Bug ID: 108561
Summary: std::endl causes a flush on a bad stream
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465
Bug ID: 107465
Summary: Bogus warning: promoted bitwise complement of an
unsigned value is always nonzero
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #10 from lavr at ncbi dot nlm.nih.gov ---
> In your code, `&a->record.data[0]` is not a well-aligned access
It is well-aligned, its offset gets printed out by the very test code, and it's
2.
> because `struct attribute` is defined as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #8 from lavr at ncbi dot nlm.nih.gov ---
Consider the following code:
struct record {
unsigned char len;
unsigned short data[5];
} __attribute__((packed));
struct attribute {
unsigned char code;
struct record record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293
--- Comment #7 from lavr at ncbi dot nlm.nih.gov ---
The problem with the aligned(4) attribute is that if this structure appears as
a member of an outer packed structure, it may not be "enclosed" properly
without a gap.
The warnings are pointless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106092
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Created attachment 53201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53201&action=edit
preprocessed source
Attached! It's rather big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106092
Bug ID: 106092
Summary: Bogus -Wfree-nonheap-object
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #4 from lavr at ncbi dot nlm.nih.gov ---
Thank you for investigating this!
Like I said, it's better NOT to emit any warnings if some machinery in the
compiler is not perfect enough to recognize the danger correctly (as it used to
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Irrespective of whether atoi() is known, printing an "int" (or two) will never
produce this many characters... This, however, also seems to have triggered
some weird logic that took the entire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
Bug ID: 103835
Summary: Bogus sprintf warnings
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN]
Indeed for the segmented data address space. But in most systems it's linear,
and the warning is then architecture dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> GCC warnings are designed to "report constructions that are not inherently
> erroneous but that are risky or suggest there may have been an error."
Certainly, but the [0] size trailing memb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Bug ID: 100403
Summary: Bogus "function may return address of local variable"
warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
Bug ID: 100401
Summary: Bogus -Wformat-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395
Bug ID: 100395
Summary: Bogus -Wstringop-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
25 matches
Mail list logo
