Topic: Defining the behavior of std::string(nullptr)

Author: Jim Porter <jvp4846@g.rit.edu>
Date: Mon, 08 Sep 2014 14:05:46 -0500 Raw View 
Does it make sense to define the behavior of std::string(nullptr)?
Currently, this would call the std::string(const char *s) constructor,
but it violates the precondition that s has at least traits::length(s) +
1 elements.

Since you can guarantee at compile-time that this isn't true for
nullptr, I think it would make sense to raise an error during
compilation. I imagine an implementation is already free to do this, but
standardizing it would eliminate a source of potential segfaults.

- Jim

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: David Krauss <potswa@gmail.com>
Date: Tue, 9 Sep 2014 10:20:13 +0800 Raw View 
--Apple-Mail=_925AE5D9-2D16-423F-823A-011C83FB6C76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-09, at 3:05 AM, Jim Porter <jvp4846@g.rit.edu> wrote:

> Does it make sense to define the behavior of std::string(nullptr)? Curren=
tly, this would call the std::string(const char *s) constructor, but it vio=
lates the precondition that s has at least traits::length(s) + 1 elements.
>=20
> Since you can guarantee at compile-time that this isn't true for nullptr,=
 I think it would make sense to raise an error during compilation. I imagin=
e an implementation is already free to do this, but standardizing it would =
eliminate a source of potential segfaults.

Checking pointer parameters of every function against nullptr just makes mo=
re work for lightweight processors. If the library wants to eliminate segfa=
ults, it can throw std::invalid_argument, or do anything else, because it's=
 UB.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_925AE5D9-2D16-423F-823A-011C83FB6C76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;09, at 3:05 AM, Jim Porter &lt;<a href=3D"mailto:jvp4846@g.r=
it.edu">jvp4846@g.rit.edu</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite">Does it make sense to define the behav=
ior of std::string(nullptr)? Currently, this would call the std::string(con=
st char *s) constructor, but it violates the precondition that s has at lea=
st traits::length(s) + 1 elements.<br><br>Since you can guarantee at compil=
e-time that this isn't true for nullptr, I think it would make sense to rai=
se an error during compilation. I imagine an implementation is already free=
 to do this, but standardizing it would eliminate a source of potential seg=
faults.<br></blockquote><div><br></div><div>Checking pointer parameters of =
every function against <font face=3D"Courier">nullptr</font> just makes mor=
e work for lightweight processors. If the library wants to eliminate segfau=
lts, it can throw <font face=3D"Courier">std::invalid_argument</font>, or d=
o anything else, because it&rsquo;s UB.</div><div><br></div></div></body></=
html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_925AE5D9-2D16-423F-823A-011C83FB6C76--

.

Author: Jim Porter <jvp4846@g.rit.edu>
Date: Mon, 08 Sep 2014 21:48:43 -0500 Raw View 
On 9/8/2014 9:20 PM, David Krauss wrote:
>
> On 2014-09-09, at 3:05 AM, Jim Porter <jvp4846@g.rit.edu
> <mailto:jvp4846@g.rit.edu>> wrote:
>
>> Does it make sense to define the behavior of std::string(nullptr)?
>> Currently, this would call the std::string(const char *s) constructor,
>> but it violates the precondition that s has at least traits::length(s)
>> + 1 elements.
>>
>> Since you can guarantee at compile-time that this isn't true for
>> nullptr, I think it would make sense to raise an error during
>> compilation. I imagine an implementation is already free to do this,
>> but standardizing it would eliminate a source of potential segfaults.
>
> Checking pointer parameters of every function against nullptr just makes
> more work for lightweight processors. If the library wants to eliminate
> segfaults, it can throw std::invalid_argument, or do anything else,
> because it's UB.

What I meant was to add a deleted std::basic_string(std::nullptr_t)
constructor. That wouldn't affect runtime performance at all, and would
just make a small subset of programs with UB fail to compile. Granted,
it's an edge case, and this overload wouldn't catch problems where you
had a null char*, but it's easy to add a deleted constructor like this,
and it prevents *some* UB from compiling.

The main thing I'm trying to prevent is implicit conversions from
nullptr to a std::string. Obviously, std::string(const char*) should
allow for implicit conversions in general, but that makes it possible to
pass nullptr to a function that expects a std::string and now you have
UB (probably a segfault) instead of just a compilation error. Adding a
deleted constructor taking a std::nullptr_t would close that admittedly
small hole at no runtime cost, and only a small compile-time cost.

- Jim

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: David Krauss <potswa@gmail.com>
Date: Tue, 9 Sep 2014 11:08:57 +0800 Raw View 
On 2014-09-09, at 10:48 AM, Jim Porter <jvp4846@g.rit.edu> wrote:

> The main thing I'm trying to prevent is implicit conversions from nullptr=
 to a std::string. Obviously, std::string(const char*) should allow for imp=
licit conversions in general, but that makes it possible to pass nullptr to=
 a function that expects a std::string and now you have UB (probably a segf=
ault) instead of just a compilation error. Adding a deleted constructor tak=
ing a std::nullptr_t would close that admittedly small hole at no runtime c=
ost, and only a small compile-time cost.

Oh, OK. That sounds like a library defect. Try asking Alisdair.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Tue, 9 Sep 2014 08:07:28 +0100 Raw View 
Deleted constructor sounds like a fine idea to me. Always good to catch thi=
ngs at compile time.

> On 9 Sep 2014, at 04:08, David Krauss <potswa@gmail.com> wrote:
>=20
>=20
>> On 2014-09-09, at 10:48 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
>>=20
>> The main thing I'm trying to prevent is implicit conversions from nullpt=
r to a std::string. Obviously, std::string(const char*) should allow for im=
plicit conversions in general, but that makes it possible to pass nullptr t=
o a function that expects a std::string and now you have UB (probably a seg=
fault) instead of just a compilation error. Adding a deleted constructor ta=
king a std::nullptr_t would close that admittedly small hole at no runtime =
cost, and only a small compile-time cost.
>=20
> Oh, OK. That sounds like a library defect. Try asking Alisdair.
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 10 Sep 2014 09:25:25 -0400 Raw View 
--089e01184b101540c10502b5fc7d
Content-Type: text/plain; charset=UTF-8

While I am not against the idea, I doubt that this would catch a whole lot
of issues. In particular, any null pointer that is not known at compile
time to be a null pointer, and even null pointers of a type different than
nullptr_t would not be detected. Additionally it raises the question of
where to stop, should we also add overloads that take pointers everywhere?
What about interfaces that take pair of iterators?

A slightly more useful approach would be to add an attribute [[not_null]]
to the arguments of the different functions. It would serve as explicit
documentation that null is not accepted for the programmer, and the
compiler would be able to produce diagnostics where either nullptr or a
null pointer of a different type is passed to the function.  It would still
raise the question of how the compiler/optimizer would be able to use that
information, i.e. is it undefined behavior to call such a function with a
null pointer? can the optimizer use this information to drop code? For
example:

void f(const char *msg) {
    std::string s(msg);
    if (!msg) {
        std::cout << "Hi there\n"; // could this be dropped by the
optimizer?
   }
}

But I am getting ahead of myself, let's start simple: would such an
attribute in the standard and its application to the library be useful?

    David

On Tue, Sep 9, 2014 at 3:07 AM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:

> Deleted constructor sounds like a fine idea to me. Always good to catch
> things at compile time.
>
> > On 9 Sep 2014, at 04:08, David Krauss <potswa@gmail.com> wrote:
> >
> >
> >> On 2014-09-09, at 10:48 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
> >>
> >> The main thing I'm trying to prevent is implicit conversions from
> nullptr to a std::string. Obviously, std::string(const char*) should allow
> for implicit conversions in general, but that makes it possible to pass
> nullptr to a function that expects a std::string and now you have UB
> (probably a segfault) instead of just a compilation error. Adding a deleted
> constructor taking a std::nullptr_t would close that admittedly small hole
> at no runtime cost, and only a small compile-time cost.
> >
> > Oh, OK. That sounds like a library defect. Try asking Alisdair.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01184b101540c10502b5fc7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While I am not against the idea, I doubt that this would c=
atch a whole lot of issues. In particular, any null pointer that is not kno=
wn at compile time to be a null pointer, and even null pointers of a type d=
ifferent than nullptr_t would not be detected. Additionally it raises the q=
uestion of where to stop, should we also add overloads that take pointers e=
verywhere? What about interfaces that take pair of iterators?<br><br>A slig=
htly more useful approach would be to add an attribute [[not_null]] to the =
arguments of the different functions. It would serve as explicit documentat=
ion that null is not accepted for the programmer, and the compiler would be=
 able to produce diagnostics where either nullptr or a null pointer of a di=
fferent type is passed to the function. =C2=A0It would still raise the ques=
tion of how the compiler/optimizer would be able to use that information, i=
..e. is it undefined behavior to call such a function with a null pointer? c=
an the optimizer use this information to drop code? For example:<br><br>voi=
d f(const char *msg) {<br>=C2=A0 =C2=A0 std::string s(msg);<br>=C2=A0 =C2=
=A0 if (!msg) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout &lt;&lt; &quot;Hi =
there\n&quot;; // could this be dropped by the optimizer?<br>=C2=A0 =C2=A0}=
<br>}<br><br>But I am getting ahead of myself, let&#39;s start simple: woul=
d such an attribute in the standard and its application to the library be u=
seful?<br><br>=C2=A0 =C2=A0 David<br><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Tue, Sep 9, 2014 at 3:07 AM, Jonathan Coe <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jonathanbcoe@gmail.com" target=3D"_blank">jo=
nathanbcoe@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Deleted constructor sounds like a fine idea to me. Always good to catch t=
hings at compile time.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On 9 Sep 2014, at 04:08, David Krauss &lt;<a href=3D"mailto:potswa@gma=
il.com">potswa@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; On 2014-09-09, at 10:48 AM, Jim Porter &lt;<a href=3D"mailto:jvp48=
46@g.rit.edu">jvp4846@g.rit.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; The main thing I&#39;m trying to prevent is implicit conversions f=
rom nullptr to a std::string. Obviously, std::string(const char*) should al=
low for implicit conversions in general, but that makes it possible to pass=
 nullptr to a function that expects a std::string and now you have UB (prob=
ably a segfault) instead of just a compilation error. Adding a deleted cons=
tructor taking a std::nullptr_t would close that admittedly small hole at n=
o runtime cost, and only a small compile-time cost.<br>
&gt;<br>
&gt; Oh, OK. That sounds like a library defect. Try asking Alisdair.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.or=
g/group/std-proposals/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01184b101540c10502b5fc7d--

.

Author: jim@chez-jim.net
Date: Wed, 10 Sep 2014 10:06:22 -0700 (PDT) Raw View 
------=_Part_399_463826355.1410368782738
Content-Type: text/plain; charset=UTF-8

On Monday, 8 September 2014 21:06:13 UTC+2, Jim Porter wrote:
>
> Does it make sense to define the behavior of std::string(nullptr)?
>

I was thinking about this recently, and I completely agree. Constructing or
assigning from nullptr currently results in undefined behaviour, so why not
just make it a compilation error?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_399_463826355.1410368782738
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, 8 September 2014 21:06:13 UTC+2, Jim Porter  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Does it make sense to defi=
ne the behavior of std::string(nullptr)? <br></blockquote><div><br></div><d=
iv>I was thinking about this recently, and I completely agree. Constructing=
 or assigning from nullptr currently results in undefined behaviour, so why=
 not just make it a compilation error?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_399_463826355.1410368782738--

.

Author: Jim Porter <jvp4846@g.rit.edu>
Date: Wed, 10 Sep 2014 12:45:35 -0500 Raw View 
On 9/10/2014 8:25 AM, David Rodr=C3=ADguez Ibeas wrote:
> While I am not against the idea, I doubt that this would catch a whole
> lot of issues. In particular, any null pointer that is not known at
> compile time to be a null pointer, and even null pointers of a type
> different than nullptr_t would not be detected. Additionally it raises
> the question of where to stop, should we also add overloads that take
> pointers everywhere? What about interfaces that take pair of iterators?

I think we'd only need to do this in places where a std::nullptr_t could=20
be implicitly converted to another (non-pointer) type in a way that=20
causes UB; those are the places that have caused the most confusion for=20
me. This means that any ordinary function could remain unchanged, but=20
classes might need a new overload.

> A slightly more useful approach would be to add an attribute
> [[not_null]] to the arguments of the different functions. It would serve
> as explicit documentation that null is not accepted for the programmer,
> and the compiler would be able to produce diagnostics where either
> nullptr or a null pointer of a different type is passed to the function.

This would probably be a better long-term solution, though. I imagine it=20
would help quite a bit with static analysis as well. I'm not sure what=20
should happen if [[not_null]] were applied to a non-pointer type, though=20
(especially when the type is templated and may or may not be a pointer).=20
Ideally, [[not_null]] would apply to iterators and smart pointers as=20
well, but that's probably hard to do.

As long as [[not_null]] were specified to emit a compilation error when=20
passing nullptr, I'd be happy.

- Jim

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 10 Sep 2014 13:58:56 -0700 Raw View 
On Monday 08 September 2014 21:48:43 Jim Porter wrote:
> The main thing I'm trying to prevent is implicit conversions from
> nullptr to a std::string. Obviously, std::string(const char*) should
> allow for implicit conversions in general, but that makes it possible to
> pass nullptr to a function that expects a std::string and now you have
> UB (probably a segfault) instead of just a compilation error.

Why are you doing that in the first place? Sounds like this is what you want to
catch as the mistake.

Your proposal wouldn't deal with passing a null const char* pointer:

 extern void f(std::string);
 const char *ptr = nullptr;
 f(nullptr);
 f(ptr);

Why should the two calls behave differently?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 10 Sep 2014 14:00:39 -0700 Raw View 
On Wednesday 10 September 2014 09:25:25 David Rodr=EDguez Ibeas wrote:
> A slightly more useful approach would be to add an attribute [[not_null]]

I like this proposal better. It's currently allowed by a GNU extension:

[[gnu:nonnull(1)]] void f(const char *msg);
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Sep 2014 06:03:48 +0800 Raw View 
--Apple-Mail=_DB53CE71-DA7F-4802-BECD-82AD21057634
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-10, at 9:25 PM, David Rodr=EDguez Ibeas <dibeas@ieee.org> wrote:

> While I am not against the idea, I doubt that this would catch a whole lo=
t of issues.

I think it might. The problem is function parameters that have migrated fro=
m char * to std::string. Client code which passes NULL compiles the same ei=
ther way.

Pathological C users who reflexively pass NULL to opt-out of a function fea=
ture might as well be stopped at compile time.

> In particular, any null pointer that is not known at compile time to be a=
 null pointer, and even null pointers of a type different than nullptr_t wo=
uld not be detected. Additionally it raises the question of where to stop, =
should we also add overloads that take pointers everywhere? What about inte=
rfaces that take pair of iterators?

It sounds reasonable to add a nullptr_t overload to every library function =
that accepts a C string that could plausibly be considered optional.

A pair of null pointers actually forms a valid empty range.

> A slightly more useful approach would be to add an attribute [[not_null]]=
 to the arguments of the different functions.

I don't think that attribute would make sense for a std::string parameter. =
The debug mode standard library might include a sanity check in std::string=
::string(char const*), and that sanity check could be generated by a [[not_=
null]] facility. The nullptr_t overload would prevent reaching that constru=
ctor, so that approach would be complementary.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_DB53CE71-DA7F-4802-BECD-82AD21057634
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;10, at 9:25 PM, David Rodr=EDguez Ibeas &lt;<a href=3D"mailt=
o:dibeas@ieee.org">dibeas@ieee.org</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">While I am n=
ot against the idea, I doubt that this would catch a whole lot of issues. <=
/div></blockquote><div><br></div><div>I think it might. The problem is func=
tion parameters that have migrated from <font face=3D"Courier">char *</font=
> to <font face=3D"Courier">std::string</font>. Client code which passes <f=
ont face=3D"Courier">NULL</font> compiles the same either way.</div><div><b=
r></div><div>Pathological C users who reflexively pass NULL to opt-out of a=
 function feature might as well be stopped at compile time.</div><br><block=
quote type=3D"cite"><div dir=3D"ltr">In particular, any null pointer that i=
s not known at compile time to be a null pointer, and even null pointers of=
 a type different than nullptr_t would not be detected. Additionally it rai=
ses the question of where to stop, should we also add overloads that take p=
ointers everywhere? What about interfaces that take pair of iterators?<br><=
/div></blockquote><div><br></div><div>It sounds reasonable to add a <font f=
ace=3D"Courier">nullptr_t</font> overload to every library function that ac=
cepts a C string that could plausibly be considered optional.</div><div><br=
></div><div>A pair of null pointers actually forms a valid empty range.</di=
v><br><blockquote type=3D"cite"><div dir=3D"ltr">A slightly more useful app=
roach would be to add an attribute [[not_null]] to the arguments of the dif=
ferent functions. </div></blockquote><div><br></div><div>I don&rsquo;t thin=
k that attribute would make sense for a <font face=3D"Courier">std::string<=
/font> parameter. The debug mode standard library might include a sanity ch=
eck in <font face=3D"Courier">std::string::string(char const*)</font>, and =
that sanity check could be generated by a <font face=3D"Courier">[[not_null=
]]</font> facility. The <font face=3D"Courier">nullptr_t</font> overload wo=
uld prevent reaching that constructor, so that approach would be complement=
ary.</div></div><br></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_DB53CE71-DA7F-4802-BECD-82AD21057634--

.

Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 10 Sep 2014 15:11:30 -0700 Raw View 
On Thursday 11 September 2014 06:03:48 David Krauss wrote:
> > In particular, any null pointer that is not known at compile time to be a
> > null pointer, and even null pointers of a type different than nullptr_t
> > would not be detected. Additionally it raises the question of where to
> > stop, should we also add overloads that take pointers everywhere? What
> > about interfaces that take pair of iterators?
> It sounds reasonable to add a nullptr_t overload to every library function
> that accepts a C string that could plausibly be considered optional.

Why stop with nullptr_t? Add an overload that takes const void* so we catch
any other types of pointers.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Sep 2014 06:15:53 +0800 Raw View 
--Apple-Mail=_E0CFDD04-DBA1-4A6C-A99C-50FCD01BB2C8
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-11, at 6:11 AM, Thiago Macieira <thiago@macieira.org> wrote:

> Why stop with nullptr_t? Add an overload that takes const void* so we catch
> any other types of pointers.

Other pointers don't implicitly convert to char *. (There is such a nonconforming extension which GCC applies in C mode, but not C++.)

Anyway, passing NULL as a string is fairly common. You might say it only *was* common in neanderthal days, but bad habits die slow.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_E0CFDD04-DBA1-4A6C-A99C-50FCD01BB2C8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;11, at 6:11 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">Why stop with nullptr_t? Add =
an overload that takes const void* so we catch <br>any other types of point=
ers.<br></blockquote><div><br></div><div>Other pointers don&rsquo;t implici=
tly convert to char *. (There is such a nonconforming extension which GCC a=
pplies in C mode, but not C++.)</div></div><br><div>Anyway, passing NULL as=
 a string is fairly common. You might say it only *<i>was</i>* common in ne=
anderthal days, but bad habits die slow.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_E0CFDD04-DBA1-4A6C-A99C-50FCD01BB2C8--

.

Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 10 Sep 2014 16:49:20 -0700 Raw View 
--001a11c268cac838c30502beb508
Content-Type: text/plain; charset=UTF-8

On 10 September 2014 15:03, David Krauss <potswa@gmail.com> wrote:

> Pathological C users who reflexively pass NULL to opt-out of a function
> feature might as well be stopped at compile time.
>

if NULL is defined as "0" (as it still tends to be on many systems, because
changing it tends to break existing [but dubious] code), will the nullptr_t
constructor be either a better or ambiguous match?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c268cac838c30502beb508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 10 September 2014 15:03, Dav=
id Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=
=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div>Pathological C users who reflexiv=
ely pass NULL to opt-out of a function feature might as well be stopped at =
compile time.</div><span class=3D""></span></blockquote></div><div class=3D=
"gmail_extra"><br></div>if NULL is defined as &quot;0&quot; (as it still te=
nds to be on many systems, because changing it tends to break existing [but=
 dubious] code), will the nullptr_t constructor be either a better or ambig=
uous match?<br>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a=
 href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c268cac838c30502beb508--

.

Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Sep 2014 07:53:26 +0800 Raw View 
--Apple-Mail=_BAEAD01C-FA99-4EA7-BB8B-F6ACC435FBC2
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-11, at 7:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 10 September 2014 15:03, David Krauss <potswa@gmail.com> wrote:
> Pathological C users who reflexively pass NULL to opt-out of a function feature might as well be stopped at compile time.
>
> if NULL is defined as "0" (as it still tends to be on many systems, because changing it tends to break existing [but dubious] code), will the nullptr_t constructor be either a better or ambiguous match?

Does it matter? One is diagnosed as selection of a deleted overload and the other is diagnosed as no selection at all. In both cases the diagnostics will (in practice) mention the nullptr overload.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_BAEAD01C-FA99-4EA7-BB8B-F6ACC435FBC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;11, at 7:49 AM, Nevin Liber &lt;<a href=3D"mailto:nevin@evil=
overlord.com">nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra">On 10 September 2014 15:03, David Krauss <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com=
</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>Pathological C users who reflexively pass NULL to opt-out of =
a function feature might as well be stopped at compile time.</div><span cla=
ss=3D""></span></blockquote></div><div class=3D"gmail_extra"><br></div>if N=
ULL is defined as "0" (as it still tends to be on many systems, because cha=
nging it tends to break existing [but dubious] code), will the nullptr_t co=
nstructor be either a better or ambiguous match?<br></div></div></blockquot=
e><div><br></div><div>Does it matter? One is diagnosed as selection of a de=
leted overload and the other is diagnosed as no selection at all. In both c=
ases the diagnostics will (in practice) mention the nullptr overload.</div>=
</div><br></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_BAEAD01C-FA99-4EA7-BB8B-F6ACC435FBC2--

.

Author: Jim Porter <jvp4846@g.rit.edu>
Date: Wed, 10 Sep 2014 20:45:33 -0500 Raw View 
On 9/10/2014 3:58 PM, Thiago Macieira wrote:
> On Monday 08 September 2014 21:48:43 Jim Porter wrote:
>> The main thing I'm trying to prevent is implicit conversions from
>> nullptr to a std::string. Obviously, std::string(const char*) should
>> allow for implicit conversions in general, but that makes it possible to
>> pass nullptr to a function that expects a std::string and now you have
>> UB (probably a segfault) instead of just a compilation error.
>
> Why are you doing that in the first place? Sounds like this is what you want to
> catch as the mistake.
>
> Your proposal wouldn't deal with passing a null const char* pointer:
>
>  extern void f(std::string);
>  const char *ptr = nullptr;
>  f(nullptr);
>  f(ptr);
>
> Why should the two calls behave differently?

Mainly because one is easy to catch with the existing language rules
(nullptr), and one is hard to (ptr). :)

- Jim


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: Christopher Jefferson <chris@bubblescope.net>
Date: Mon, 15 Sep 2014 13:27:34 +0100 Raw View 
The following program is (I believe) valid C++11, and would break if
you added a deleted nullptr constructor to std::string.

#include <iostream>
#include <string>
#include <ostream>

using namespace std;

template<typename ptr>
string make_string(ptr p)
{
    if(p)
        return string(p);
    else
        return string("<NULL>");
}

int main(void)
{ std::cout << make_string("hello") << make_string((char*)0) <<
make_string(nullptr) << "\n"; }



On 11 September 2014 02:45, Jim Porter <jvp4846@g.rit.edu> wrote:
> On 9/10/2014 3:58 PM, Thiago Macieira wrote:
>>
>> On Monday 08 September 2014 21:48:43 Jim Porter wrote:
>>>
>>> The main thing I'm trying to prevent is implicit conversions from
>>> nullptr to a std::string. Obviously, std::string(const char*) should
>>> allow for implicit conversions in general, but that makes it possible to
>>> pass nullptr to a function that expects a std::string and now you have
>>> UB (probably a segfault) instead of just a compilation error.
>>
>>
>> Why are you doing that in the first place? Sounds like this is what you
>> want to
>> catch as the mistake.
>>
>> Your proposal wouldn't deal with passing a null const char* pointer:
>>
>>         extern void f(std::string);
>>         const char *ptr = nullptr;
>>         f(nullptr);
>>         f(ptr);
>>
>> Why should the two calls behave differently?
>
>
> Mainly because one is easy to catch with the existing language rules
> (nullptr), and one is hard to (ptr). :)
>
> - Jim
>
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: David Krauss <potswa@gmail.com>
Date: Mon, 15 Sep 2014 21:00:29 +0800 Raw View 
On 2014-09-15, at 8:27 PM, Christopher Jefferson <chris@bubblescope.net> wrote:

> The following program is (I believe) valid C++11,

But do you believe it to be reasonable?

It's not in outer space, but it is a mishmash of generic and old-school.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Author: Christopher Jefferson <chris@bubblescope.net>
Date: Mon, 15 Sep 2014 14:39:29 +0100 Raw View 
On 15 September 2014 14:00, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-09-15, at 8:27 PM, Christopher Jefferson <chris@bubblescope.net> wrote:
>
>> The following program is (I believe) valid C++11,
>
> But do you believe it to be reasonable?
>
> It's not in outer space, but it is a mishmash of generic and old-school.

It's certainly reasonable to have a wrapper function for constructing
a std::string from a pointer which checks if the pointer is NULL, as
constructing a string from NULL is undefined behaviour. Is it valid to
write it in this way? It is certainly strange code but (in general) we
try to avoid breaking correct programs.

Also, this only partially patches up the problem and not in a way I
would like to rely on (as if you ever turn the nullptr into a
(char*)0, then you move from doesn't compile to UB). In general, I
would personally prefer to keep null pointers and nullptr acting in
the same way.

If we just wanted to make std::string((char*)0) defined behaviour,
that would seem to be easier. I know that g++ makes this code defined
(and makes an empty string). Has anyone checked what other compilers
do?

Chris

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.