Hi Paul,
Thanks -- fixed. All 12 you listed do `return string()` now instead of
`return 0` (your reading was right: those `bad_get()` fallbacks return
`std::string`, and `return 0` constructs one from a null `const char*`,
UB that glibc/libstdc++ happens not to choke on). While I was in there
I found and fixed a 13th instance of the identical pattern your build
didn't warn about: `get__MATCH_OR_MAKE__varname` (Svar_signals.hh:583).
Fixed in *SVN 2108*.
Cheers,
Jürgen
PS: this reply and the fix were verified with Claude Code against a
clean Linux/GCC build and the full regression suite (no crash there
either way, as you'd expect for undefined rather than defined-wrong
behavior) -- no clang toolchain here, so as always I'm relying on your
build to confirm the warning is actually gone.
On 8/25/26 18:47, Paul Rockwell wrote:
While compiling code that includes Svar_signals.hh on macOS (Apple
clang version 21.0.0 (clang-2100.1.1.101) , I get the following warnings:
*./Svar_signals.hh:473:46: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
473 | { bad_get("SET_STATE", "sloc"); return0; }
| * ^*
*./Svar_signals.hh:497:50: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
497 | { bad_get("VALUE_IS", "error_loc"); return0; }
| * ^*
*./Svar_signals.hh:499:50: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
499 | { bad_get("VALUE_IS", "cdr_value"); return0; }
| * ^*
*./Svar_signals.hh:507:54: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
507 | { bad_get("ASSIGN_VALUE", "cdr_value"); return0; }
| * ^*
*./Svar_signals.hh:516:55: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
516 | { bad_get("SVAR_ASSIGNED", "error_loc"); return0; }
| * ^*
*./Svar_signals.hh:547:53: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
547 | { bad_get("SVAR_RECORD_IS", "record"); return0; }
| * ^*
*./Svar_signals.hh:577:59: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
577 | { bad_get("REGISTER_PROCESSOR", "progname"); return0; }
| * ^*
*./Svar_signals.hh:583:53: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
583 | { bad_get("MATCH_OR_MAKE", "varname"); return0; }
| * ^*
*./Svar_signals.hh:630:65: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
630 | { bad_get("OFFERING_PROCS_ARE", "offering_procs"); return0; }
| * ^*
*./Svar_signals.hh:644:61: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
644 | { bad_get("OFFERED_VARS_ARE", "offered_vars"); return0; }
| *^*
*./Svar_signals.hh:708:57: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
708 | { bad_get("ASSIGN_WSWS_VAR", "cdr_value"); return0; }
| * ^*
*./Svar_signals.hh:718:55: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
718 | { bad_get("WSWS_VALUE_IS", "cdr_value"); return0; }
| * ^*
*./Svar_signals.hh:727:56: **warning: **null passed to a callee*
* that requires a non-null argument [-Wnonnull]*
727 | { bad_get("SVAR_DB_PRINTED", "printout"); return0; }
| * ^*
*
*
These warnings appear to occur when the return type of the method
definitions that contain this code is "string", which I interpret to
be the C++ std::string data type.
Claude indicates that std::string is an object, not a pointer, so it
can't be assigned null (or any value that it can prove is null such as
the number 0).
These warnings don't seem to appear on Linux/GCC - it looks like it is
another case where g++ is more lenient.
Switching those to a string constant of "0" does make the warning go
away, but I haven't run extensive testing to see if that's going break
anything.
- Paul
