On 14/06/18 17:51 +0100, Jonathan Wakely 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 implem
On 06/14/2018 10:54 AM, Ville Voutilainen wrote:
On 14 June 2018 at 19:51, Jonathan Wakely 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 constructo
On 14 June 2018 at 20:40, Jonathan Wakely wrote:
>> Namely "For an attribute-token (including an attribute-scoped-token)
>> not specified in this document, the behavior is
>> implementation-defined.", aka [dcl.attr.grammar]/6.
>
>
> As I said on IRC, if the user does
>
> #define gnu R"(
> ,= ,-_-.
On 14/06/18 20:27 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 20:21, Ville Voutilainen wrote:
On 14 June 2018 at 20:08, Jonathan Wakely wrote:
Oops, indeed. But for gnu-attributes, surely we can decide whatever we
want about what's
valid and what's not?
We could say that #defining '
On 14 June 2018 at 20:21, Ville Voutilainen wrote:
> On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>>> want about what's
>>> valid and what's not?
>>
>>
>> We could say that #defining 'nonnull' and/or 'gnu' as a macro i
On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>> want about what's
>> valid and what's not?
>
>
> We could say that #defining 'nonnull' and/or 'gnu' as a macro is
> undefined, but then programs that the standard says are
On 14/06/18 20:02 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 19:57, Jonathan Wakely wrote:
[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 w
On 14 June 2018 at 19:57, Jonathan Wakely wrote:
>> [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
On 14/06/18 19:54 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 19:51, Jonathan Wakely 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 construct
On 14 June 2018 at 19:51, Jonathan Wakely 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 che
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
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.
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?
commit 05d33d55
13 matches
Mail list logo
