Sorry for the delay in testing this out. Confirming that SVN 2110 builds without the warning on my macOS configuration.
- Paul > On Sep 3, 2026, at 1:03 PM, Dr. Jürgen Sauermann > <[email protected]> wrote: > > 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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./Svar_signals.hh:577:59: warning: null passed to a callee >> that requires a non-null argument [-Wnonnull] >> 577 | { bad_get("REGISTER_PROCESSOR", "progname"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> ./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"); return 0; } >> | ^ >> >> 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 >> >
