This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Decorate string_view members with nonnull attribute
On 06/14/2018 10:54 AM, 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.
Okay, that's good to know about the one that uses the standard
attribute (and thanks for the reference). WG14 should consider
this when integrating attributes into C2X.
FWIW, the problem I suspect will come up in WG14 is that C tries
hard to avoid introducing new reserved words into the public
namespace. At the same time, two of the biggest selling points
of the C++ attribute syntax proposal in WG14 (i.e., the double
brackets, as opposed to something more C-ish like _Attribute())
are a) compatibility and interoperability with C++ and b) being
able to avoid relying on preprocessor conditionals and macros
to use attributes in portable code. If C2X programs (and
libraries) are going to continue to be allowed to #define macros
with the same names as even standard attributes, we (i.e., both
WG14 and to an extent even WG21) will have failed to deliver on
these goals. To avoid name clashes, mixed C/C++ programs will
still have to use #ifdefs and macros in both languages to make
use of attributes because the spelling of the "private" attribute
names (like __noreturn__) is not specified. Even if C2X were to
impose the same restriction on macros as C++, there likely are
C headers out there today that do just that, and not all those
headers will necessarily migrate to C2X.
Martin