[Bug c++/56556] Wshadow warns for private members in base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56556 Pierre Ossman changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #5 from Pierre Ossman --- We're also getting bit by this when porting TigerVNC to Qt. -Wshadow avoids bugs, so it would be very nice to not end up having to disable it.
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 Pierre Ossman changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #9 from Pierre Ossman --- I'd like to add a dissenting voice. I think the current behaviour is useful. In your simple example, yes, it provides no value. But in a more complex constructor with a body, then it's important to access the *member* foo, not the *argument* foo. Otherwise, you might modify the wrong thing.
[Bug c++/115664] -Wnonnull-compare breaks templated methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664 --- Comment #9 from Pierre Ossman --- Thank you! That worked nicely!
[Bug c++/115664] -Wnonnull-compare breaks templated methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664 --- Comment #6 from Pierre Ossman --- Is there a cleaner way to can work around this than duplicating the affected methods? I tried adding a #pragma, but that breaks older versions of gcc that don't have -Wnonnull-compare.
[Bug c++/115664] New: -Wnonnull-compare breaks templated methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664
Bug ID: 115664
Summary: -Wnonnull-compare breaks templated methods
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
A templated method has this protection in it to check that a given argument is
a subclass:
template
Object::method(void (*callback)(T*))
{
if (dynamic_cast(this) == nullptr)
throw Exception("Bad callback");
registerCallback(callback);
}
This works fine as long as T is a subclass of Object. However, if T is Object,
then the gcc is clever enough to realise that dynamic_cast<>() does nothing and
the comparison becomes just "if (this == nullptr)", which triggers
-Wnonnull-compare.
The problem is that this is a templated method, so that if statement is
sometimes useful and cannot be removed.
Presently, we have to work around the issue by having a specialised version of
the affected methods, which adds unnecessary duplication.
[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #3 from Pierre Ossman --- And another odd case; gcc 5 complains about this: > const char *a; > a = NULL; but not: > const char *a = NULL; gcc 13 complains about neither, and clang about both.
[Bug c++/114573] -Wzero-as-null-pointer-constant complains on enum with explicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573 --- Comment #2 from Pierre Ossman --- Indeed. It is part of an effort to have a more modern C++ style in TigerVNC. One item was preferring nullptr over NULL, and this issue became an obstacle there. Right now, we did a #pragma, but if there is a better workaround, then we are all ears.
[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #2 from Pierre Ossman --- Found another case that neither gcc 5, gcc 13, nor clang complain about for some odd reason: > assert(thing == NULL); All three complain about: > assert(thing == 0); Not sure what's going on here.
[Bug c++/114573] New: -Wzero-as-null-pointer-constant complains on enum with explicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573
Bug ID: 114573
Summary: -Wzero-as-null-pointer-constant complains on enum with
explicit cast
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
g++ complains about the following code when -Wzero-as-null-pointer-constant is
given:
> enum { ZERO, ONE, TWO };
>
> extern int func(const char *a);
>
> void zeroenum()
> {
> func((const char*)ZERO);
> }
Oddly enough, it also gives the wrong location for the issue:
> nulls.cxx: In function ‘void zeroenum()’:
> nulls.cxx:8:1: warning: zero as null pointer constant
> [-Wzero-as-null-pointer-constant]
> 8 | }
> | ^
clang does not complain about this, neither does older versions of gcc (tested
with 5.5.0). So it's some form of regression.
The above example is a bit contrived, but this pattern is moderately common in
that an argument can be either a pointer or an integer. E.g. CopyFromParent in
libX11, or FLTK menus.
[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #1 from Pierre Ossman --- Hmm.. I found bug 77513, and r9-873. So I guess this is intentional? This makes the warning somewhat pointless. We want to make sure developers standardise on nullptr, both for style and since the behaviour of NULL is compiler dependent (if I'm understanding the C++ standard correctly). It's also annoying if there is not a consensus between clang and gcc here.
[Bug c++/114571] New: -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 Bug ID: 114571 Summary: -Wzero-as-null-pointer-constant does not complain about NULL Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- Created attachment 57857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57857&action=edit Test case We are looking at bringing up the TigerVNC project to a more modern C++ style, and one thing was using nullptr instead of NULL. We were very glad when we found -Wzero-as-null-pointer-constant to help out with this. Unfortunately, it doesn't seem to do much for NULL in modern¹ gcc. It spots usage of "0", but not any "NULL". clang has no trouble finding both. I've attached a test case with some comments on the cases we've seen. ¹ gcc 5 spots some, but not all NULL
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #5 from Pierre Ossman --- Could you consider adding -fconstant-cfstrings as an alias? It would make life easier for making build systems compiler agnostic.
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #4 from Pierre Ossman --- I am indeed trying to compile for macOS. Specifically Qt5, which is designed with just Xcode in mind.
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #2 from Pierre Ossman --- Great news. And that is the same thing as clang's -fconstant-cfstrings? Unfortunately, I couldn't see -mconstant-cfstrings in gcc's documentation, but I may be looking in the wrong place.
[Bug objc/108743] New: -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 Bug ID: 108743 Summary: -fconstant-cfstrings not supported Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- Some programs designed for clang want this flag. I'm unsure exactly how important it is. The description sounds like it's just some optimization. To make things worse, it is mentioned in gcc's documentation even though it isn't supported.
