[PATCH] Decorate string_view members with nonnull attribute
Jonathan Wakely
jwakely@redhat.com
Thu Jun 14 16:57:00 GMT 2018
On 14/06/18 19:54 +0300, Ville Voutilainen wrote:
>On 14 June 2018 at 19:51, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 14/06/18 10:46 -0600, Martin Sebor wrote:
>>>
>>> On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
>>>>
>>>> The C++ committee has confirmed that passing a null pointer to the
>>>> unary basic_string_view constructor is undefined. This removes the check
>>>> from our implementation, and adds the nonnull attribute to warn when the
>>>> compiler can detect undefined input.
>>>>
>>>> Any objections to this change?
>>>
>>>
>>> I have a general question about using the new C++ attributes in
>>> libstdc++ (standard or otherwise): what does C++ have to say about
>>> programs that define macros with the same names? E.g., is this
>>> a valid program?
>>>
>>> #define nonnull "..."
>>> ...
>>> #include <string_view>
>>>
>>> How about:
>>>
>>> #define noreturn "..."
>>> ...
>>> #include <string_view>
>>>
>>> The view in WG14 is that the corresponding C programs (if C2X
>>> were to adopt the proposed C++ attributes) would be valid and
>>> that it's up to implementations to make it work.
>>
>>
>> Good point, I suppose I have to use __attribute__((__nonnull__))
>> instead. The reason I didn't is that I find the grammar for the
>> position of C++11 attributes much easier to understand. But in this
>> instance the same location works for either.
>
>[macro.names]/2 forbids #defining macros with the same names as the
>standard attributes.
>The programs Martin shows as examples are not valid.
But nonnull isn't a standard attribute though. So we can't use
[[gnu::xxx]] attributes in libstdc++ and have to use __attribute__
instead.
[[sad_face]]
More information about the Libstdc++
mailing list