std::string add nullptr attribute

[Jonny Grant]

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.

I see, yes it is tricky, as many functions take NULL, like time(NULL) from <time.h>, need to actually dereference it to get the build warning!

that basic_string() constructor doesn't dereference the nullptr as it throws logic_error("construction from null is not valid")


So then I am back to putting my actual dereference in, just in that build where it is enabled

TRIGGER_NULLPTR_WARNING
https://godbolt.org/z/4h3MqGh1s

I added myassert() to catch it otherwise so I can at least get the file and line info rather than just the basic_string exception throw logic_error message


> 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.

You're right, I shouldn't rely on this logic_error which maybe specific to GNU.
I made another example that wraps, and also catches exceptions
https://godbolt.org/z/ez3q76cj4

There was an issue as char_traits does __builtin_strlen() which doesn't check for nullptr so crashes, so I couldn't just do out_string = str;


>> 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.

That's a good point. I've seen C++ programs sometimes don't have good exception handling, some don't have any at all, it goes right back to the top and calls abort() when there's a std::out_of_range exception etc.

It would be good to have the opportunity to see a build warning when there would be an uncaught exception the optimizer knows about.

Kind regards
Jonny