On 20/02/2023 12:59, Xi Ruoyao wrote: > 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. Well seeing something like this would be useful at build time for me: app.cpp: In function 'int connect_usb()': app.cpp:16:7: warning: unhandled throw std::logic_error("my string: construction from null is not valid") It's true it's very difficult to handle all uncatched exceptions. At least the software might restart that module (maybe using a watchdog if it finds that module unresponsive for a number of seconds, no heartbeat etc) after informing the user of an issue (my example would be when an unsupported USB device is connected to something in an embedded system, a car infotainment system - driver fails, but at least it could be restarted by the software), if we had the ID of the USB device, we can keep it in a forbid list, so it doesn't try to use it again. Otherwise the software would keep crashing in a multiple times while such a device was connected if that device wasn't forbidden. Anyway, this is all automotive specific. There's a standard committee paper "Unconditional termination is a serious problem" P2698R0. Not exactly the same, but it's a similar topic. Kind regards Jonny
