On Mon, 2023-02-20 at 11:30 +0000, Jonny Grant wrote: > Thank you for the suggestion, I gave that nonnull attribute a try, but > it doesn't appear to warn for this example. > > https://godbolt.org/z/boqTj6oWE Ouch... The optimizer inlined make_std_string so both -Wnonnull and - fanalyzer fails to catch the issue here. Adding noipa attribute for make_std_string will work, but will also cause the generated code stupidly slow. Maybe: #ifdef WANT_DIAGNOSTIC #define MAKE_STD_STRING_ATTR __attribute__ ((noipa, nonnull)) #else #define MAKE_STD_STRING_ATTR #endif std::string make_std_string(const char * const str) MAKE_STD_STRING_ATTR; It still looks very stupid though. > Feels useful to get build warnings if compiler knows nullptr is going > to be dereferenced, as clang does. The problem is in this case nullptr is not dereferenced, at all. So if we want a warning here we'll have to invent some new __builtin or __attribute__ to give the compiler a hint. AFAIK there is no such facility now. And you cannot simply justifying to add a new facility because "I feel it useful". Generally you need to show the benefit will be at least equally great than the maintenance burden introduced into the GCC code base. And unfortunately usually we can only measure the burden after really writing all the code... So it's not easy to convince someone to develop such a new feature. > Personally I feel runtime should equally handle possible nullptr by > constructing strings in a try catch block so any exceptions are > handled or logged at least... A portable runtime should not assume std::string(NULL) will raise an exception because other C++ standard libraries may behave differently. The portable solution is to make a wrapper around std::string constructor and check if the parameter is NULL. > Personally I would be pleased if GCC had a warning I could enable to > report any logic_error exceptions it knew would execute. Or maybe when a program will definitely raise an uncatched exception. But is the feature really useful? This will not happen for anything other than simple toy programs. -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
