This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Decorate string_view members with nonnull attribute
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.