repo
One command was observed. Code it does not exercise is not observed; "no difference" means the normalized output and exit status matched, not that the fix is correct.
modernize-use-nullptrfix changes program behavior
- files changed
- 2: native/src/names.cpp, native/tests/tests.cpp
- reduced to
- 1 of 2 hunk(s) in native/tests/tests.cpp, 1 run(s), budget exhausted; the patch was applied with git apply and reproduced the same difference
- sites reported
- 2 → 0 in 2 linted file(s)
Change (reduced)
--- a/native/tests/tests.cpp +++ b/native/tests/tests.cpp @@ -16,7 +16,7 @@ Window off(0); CHECK(disabled(off)); CHECK(normalize("MiXed") == "mixed"); - CHECK(first_or_null("") == NULL); + CHECK(first_or_null("") == nullptr); CHECK(std::strcmp(first_or_null("a"), "a") == 0); std::cout << (failures ? "FAILED" : "PASSED") << "\n"; return failures ? 1 : 0;
Observed
stdout lines only before the fix:
ok first_or_null("") == NULL
stdout lines only after the fix:
ok first_or_null("") == nullptrOutput after tail
ok !disabled(w)
ok w.empty()
ok w.sum() == 9
ok disabled(off)
ok normalize("MiXed") == "mixed"
ok first_or_null("") == nullptr
ok std::strcmp(first_or_null("a"), "a") == 0
PASSEDJudge Nemotron 3 Ultra, advisory
The only difference is the test framework printing the rewritten source text 'nullptr' instead of 'NULL' in its diagnostic output. The rule replaces the NULL macro with nullptr, which is a source-text change that the test harness reflects in its 'ok' line. No runtime semantics, environment, or pre-existing failure is involved.
Explanation Nemotron 3 Super, model draft
The macro `NULL` expands to an integer constant expression of type int with value zero, while `nullptr` has type `std::nullptr_t`. When comparing via overloaded operators or templates—such as in a custom `CHECK` macro that may inspect types—the two expressions yield different compile-time properties, potentially causing distinct overload resolutions or template instantiations. This can alter runtime behavior if the test harness relies on type-specific logic, such as printing different messages based on the operand types, leading to divergent output despite identical logical values. Thus, the substitution changes observable program behavior.
Upstream
Files
readability-container-size-emptyfix changes program behavior
- files changed
- 1: native/src/window.cpp
- reduced to
- 1 of 1 hunk(s) in native/src/window.cpp, 0 run(s), budget exhausted; the patch was applied with git apply and reproduced the same difference
- sites reported
- 1 → 0 in 1 linted file(s)
Change (reduced)
--- a/native/src/window.cpp +++ b/native/src/window.cpp @@ -9,4 +9,4 @@ int Window::sum() const { return std::accumulate(samples_.begin(), samples_.end(), 0); } -bool disabled(const Window& w) { return w.size() == 0; } +bool disabled(const Window& w) { return w.empty(); }
Observed
stdout lines only before the fix: ok !disabled(w) PASSED stdout lines only after the fix: FAIL !disabled(w) FAILED exit 0 → 2 stderr last line before: (none) stderr last line after: make: *** [Makefile:6: test] Error 1
Output after tail
FAIL !disabled(w)
ok w.empty()
ok w.sum() == 9
ok disabled(off)
ok normalize("MiXed") == "mixed"
ok first_or_null("") == NULL
ok std::strcmp(first_or_null("a"), "a") == 0
FAILED
make: *** [Makefile:6: test] Error 1Judge Nemotron 3 Ultra, advisory
The rule rewrites `w.size() == 0` to `w.empty()`, which for standard containers is semantically equivalent. However, the test failure indicates that `Window::empty()` either does not exist, has a different signature, or returns a different result than `w.size() == 0`. Since the documentation is missing and the fix is labelled unknown, the rewrite cannot be assumed safe for this user-defined type, and the change in test outcome demonstrates a real behavioral regression.
Explanation Nemotron 3 Super, model draft
The rewrite replaces `w.size() == 0` with `w.empty()`, which for standard containers like `std::vector` or `deque` is equivalent in behavior—both check if there are zero elements. However, if `Window::size()` returns a signed integer type (e.g., `int`) while `empty()` expects an unsigned comparison internally, or if `Window` overrides `size()` with non-standard semantics (e.g., returning cached or approximated size), then `w.size() == 0` and `w.empty()` may diverge. For instance, if `size()` can be negative due to overflow or bug, `w.size() == 0` would be false for negative values, but `w.empty()` might still return true if the container is actually empty—though this contradicts typical design. More plausibly, if `Window` is not a standard container and `empty()` is not overridden to match `size() == 0`, the two expressions differ. The test failure indicates that for some `w`, `w.size() == 0` is true but `w.empty()` is false (or vice versa), breaking equivalence. Since the fix assumes `empty()` mirrors `size() == 0`, it fails when `Window` does not uphold that contract—making the change unsafe without verifying `Window`'s actual behavior. The observed shift from passing to failing confirms the semantic mismatch.
Upstream
Files
Applied without a difference
1 rule(s) changed 1 file(s) with no difference under the command, applied together. accepted.patch applies with git apply -p1. readability-redundant-string-cstr