Re: std::string add nullptr attribute

[Jonny Grant <jg@jguk.org>]

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