Fix #15080 FP uninitMemberVarNoCtor for const and reference members by autoantwort · Pull Request #8910 · cppcheck-opensource/cppcheck

autoantwort · 2026-10-01T16:04:27Z

https://trac.cppcheck.net/ticket/15080

struct S {
    const std::array<std::uint8_t, 2> a;
    const std::vector<std::uint8_t>::const_iterator it;
};
S f(const std::vector<std::uint8_t>& v) {
    return S{ {}, v.cbegin() };
}

gives Member variable 'S::it' has no initializer. [uninitMemberVarNoCtor], and struct S { int a = 0; const int b; int& c; }; warns for b and c.

A non-static const or reference member without default member initializer can't stay uninitialized: for trivial types the implicit default constructor is deleted, so every instance must initialize it, and a const class type is default-constructed. These members are now skipped by the no-constructor check.

Since f90a76f (#15072) this also shows up for class templates whose member type is a using alias.

This PR was created by Claude Code (an AI coding agent) on behalf of @autoantwort.

🤖 Generated with Claude Code

A class without constructor whose non-static const or reference member has no default member initializer is not default constructible (or, for a const class type with a default constructor, default constructs it), so the member can never be left uninitialized. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…or for all members Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

autoantwort · 2026-10-07T17:12:15Z

Any further changes requested?

danmar · 2026-10-07T18:21:24Z

@claude review

claude · 2026-10-07T18:23:52Z

The approach makes sense: a const member of trivial type, or a reference member, with no initializer deletes the implicit default constructor, so every instance has to be initialized another way.

One issue (inline): static const and static reference members are in the usage list too. The new check doesn't exclude them, so a declaration like static const int N; turns off uninitMemberVarNoCtor for the whole class. That's a new false negative. It needs a !var.isStatic() guard and a regression test.

Minor: it would be good to add a test for a const pointer member (int* const p;).

🤖 Generated with Claude Code

danmar · 2026-10-07T18:25:39Z

please check the results here:
http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/

Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dmcppcheck · 2026-10-09T09:53:19Z

Test results for commit d9ff8a4 (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/
packages: 200
Differing warnings: 31 (+0 -31)
AI review: 22 improvement, 8 regression, 1 unclear (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/2026-10-08_12-49-15-d9ff8a48bccd-review.txt)
Timing: -0.1% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/2026-10-08_12-49-15-d9ff8a48bccd_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

autoantwort · 2026-10-09T14:02:11Z

AI review: 22 improvement, 8 regression, 1 unclear (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/2026-10-08_12-49-15-d9ff8a48bccd-review.txt)

It is so cool to have a real would test of the changes and an automatic review of the differences

Variable::isReference() is also true for `std::string& (*f)(int)`, which suppressed uninitMemberVarNoCtor for the whole class (codelite in the PR test results). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

autoantwort · 2026-10-09T14:09:26Z

Thanks for the real-world run! I checked the 8 regressions + 1 unclear:

codelite (3): real. std::string & (*m05)(int a,int b); has isReference() set although it is a function pointer returning a reference. Fixed in fc4b65a: a member only counts as reference when &/&& is directly before its name, with tests.
mmseqs2 (5 + 1 unclear): not regressions. CommandMode is typedef const unsigned int CommandMode;, so Command has a const scalar member and is not default constructible (g++: "use of deleted function"). The AI review assumed an enum.

(Written by Claude Code on behalf of @autoantwort.)

autoantwort · 2026-10-09T14:11:42Z

+                // isReference() is also true for a function pointer that returns a reference
+                const bool isReferenceMember = var.isReference() && var.nameToken() && Token::Match(var.nameToken()->previous(), "&|&&");


I think a better fix would be to fix isReference

Claude creates a new PR for this,

There is now #8931

dmcppcheck · 2026-10-09T17:00:23Z

@claude review

claude · 2026-10-09T17:01:40Z

Re-reviewed after fc4b65a. The earlier points are addressed: there is now a !var.isStatic() guard, a test for static members, and a test for int* const p. The function-pointer-returning-reference case is handled by the &|&& check before the name.

I found no correctness bugs in the current diff:

Variable::isConst() is cleared on *, so const int* d still warns. int* const p and int (* const f)() correctly make the class non-default-constructible.
Enum and library pod types have isClass() == false, so const E e; and const uint8_t x; count as non-default-constructible, which matches the standard.
The new var.isConst() skip in the second loop only matters for const class-type members, and those are never left uninitialized.

There is one remaining false positive. It is not a regression, and a follow-up is fine. A const member of an aggregate class type with no user-provided default constructor, such as const std::array<int, 2> a; or const Pod p; with struct Pod { int x; };, also deletes the implicit default constructor. But !var.isClass() treats it as default-constructible, so in struct S { int i = 0; const std::array<int,2> a; int k; }; the check still warns about k.

🤖 Generated with Claude Code

autoantwort · 2026-10-09T19:51:09Z

There is one remaining false positive. It is not a regression, and a follow-up is fine.

I think a follow up MR is better then making this MR bigger

dmcppcheck · 2026-10-10T03:27:20Z

Test results for commit fc4b65a (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/
packages: 100
Differing warnings: 6 (+0 -6)
AI review: 6 improvement (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/2026-10-09_14-08-07-fc4b65a8e333-review.txt)
Timing: -0.0% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8910/2026-10-09_14-08-07-fc4b65a8e333_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

danmar

to me it feels like this PR has evolved into something great

well tested
It looks like the changes in the checker are limited.

of course it's approved. :-)

@autoantwort

…on pointer returning a reference (#8931) https://trac.cppcheck.net/ticket/15094 For a function pointer returning a reference, the reference of the return type was taken as reference of the variable: ```cpp struct S { std::string& (*f)(int, int); int& (*g[2])(); }; void foo(int& (*fp)(), int&& (*fp2)()); ``` `Variable::isReference()` (and `isRValueReference()` for `fp2`) was true for all of them. `Variable::evaluate()` now drops the reference collected before the `(` of a function declarator, as it belongs to the return type. A `&` after the `(` still makes the variable a reference, so `int (*&f)()`, `int (&f)()`, `int*& r`, `int (&a)[2]` and `int& (r)` are unchanged. The `ValueType` of the function pointer is not changed: the type of a call `fp()` is derived from it, so its reference has to stay the one of the return type (clearing it caused `returnTempReference` FPs). Two places relied on the wrong flags and are adjusted: - `checkConstVariable`: a reference to a function returning a reference (`int& (&f)()`) was skipped only because it was wrongly flagged as rvalue reference. References to functions are now skipped explicitly (this also fixes the existing FP for `int (&f)()`). - Copy/move constructor detection: `Foo(Foo&& (*f)())` was a move constructor. With the fix it is a normal constructor, and parameters that are references to functions (`Foo(Foo& (&f)())`) no longer make a copy/move constructor either. Found with #8910, where it suppressed `uninitMemberVarNoCtor` for a struct with such a member (codelite in the PR test results). #8910 contains a workaround in CheckClass for this; with this PR merged it can be replaced by `var.isReference()` again. This PR was created by Claude Code (an AI coding agent) on behalf of @autoantwort. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

chrchr-github reviewed Oct 2, 2026

View reviewed changes

Comment thread lib/checkclass.cpp Outdated

Const/reference member of non-class type inhibits uninitMemberVarNoCt…

b8fbea9

…or for all members Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

chrchr-github reviewed Oct 3, 2026

View reviewed changes

Comment thread test/testconstructors.cpp

claude Bot reviewed Oct 7, 2026

View reviewed changes

Comment thread lib/checkclass.cpp Outdated

autoantwort and others added 2 commits October 8, 2026 14:47

Update lib/checkclass.cpp

325020d

Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>

Add tests for const pointer and static members

d9ff8a4

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

autoantwort commented Oct 9, 2026

View reviewed changes

autoantwort mentioned this pull request Oct 9, 2026

Fix #15094 SymbolDatabase: Variable::isReference() is true for function pointer returning a reference #8931

Merged

danmar approved these changes Oct 10, 2026

View reviewed changes

danmar merged commit 07254e9 into cppcheck-opensource:main Oct 25, 2026
71 checks passed

		// isReference() is also true for a function pointer that returns a reference
		const bool isReferenceMember = var.isReference() && var.nameToken() && Token::Match(var.nameToken()->previous(), "&\|&&");

Conversation

autoantwort commented Oct 1, 2026

Uh oh!

Uh oh!

Uh oh!

autoantwort commented Oct 7, 2026

Uh oh!

danmar commented Oct 7, 2026

Uh oh!

Uh oh!

claude Bot commented Oct 7, 2026

Uh oh!

danmar commented Oct 7, 2026

Uh oh!

dmcppcheck commented Oct 9, 2026

Uh oh!

autoantwort commented Oct 9, 2026

Uh oh!

autoantwort commented Oct 9, 2026

Uh oh!

autoantwort Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

autoantwort Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

autoantwort Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

dmcppcheck commented Oct 9, 2026

Uh oh!

claude Bot commented Oct 9, 2026

Uh oh!

autoantwort commented Oct 9, 2026

Uh oh!

dmcppcheck commented Oct 10, 2026

Uh oh!

danmar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants