diff mbox

[wwwdocs] Document C++ null pointer constant changes in gcc-7/porting_to.html

Message ID 20170410122828.GD3412@redhat.com
State New
Headers show

Commit Message

Jonathan Wakely April 10, 2017, 12:29 p.m. UTC 
On 09/04/17 19:58 -0600, Sandra Loosemore wrote:
>On 04/07/2017 03:25 AM, Jonathan Wakely wrote:
>>This issue caused a lot of build failures during the GCC mass rebuilds
>>for Fedora, but isn't in the porting to guide yet.
>>
>>Is this accurate and clear enough for casual readers?
>>
>>
>>Index: htdocs/gcc-7/porting_to.html
>>===================================================================
>>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
>>retrieving revision 1.13
>>diff -u -r1.13 porting_to.html
>>--- htdocs/gcc-7/porting_to.html	6 Apr 2017 17:12:16 -0000	1.13
>>+++ htdocs/gcc-7/porting_to.html	7 Apr 2017 09:25:06 -0000
>>@@ -118,6 +118,39 @@
>> with GCC 7 and some are compiled with older releases.
>> </p>
>>
>>+<h3 id="null-pointer-constants">Null pointer constants</h3>
>>+
>>+<p>
>>+When compiling as C++11 or later, GCC 7 follows the revised definition of a
>>+<em>null pointer constant</em>. This means conversions to pointers from other
>>+types of constant (such as character literals and boolean literals) will now
>>+be rejected.
>>+</p>
>
>Nit pick: s/will now be rejected/are now rejected/
>
>since "now" means we are describing GCC's current behavior, not future 
>behavior.  :-)

If you write such code (or try to compile existing code like that) it
will now be rejected - that's the first conditional isn't it?

"It's started raining and if you go outside again you will now get
wet."

Anyway, I've committed the attached patch with that change and a
similar one you noted previously for GCC 5.
diff mbox

Patch

? htdocs/gcc-7/porting_to.TODO
Index: htdocs/gcc-5/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.11
diff -u -r1.11 porting_to.html
--- htdocs/gcc-5/porting_to.html	21 Jan 2016 22:20:29 -0000	1.11
+++ htdocs/gcc-5/porting_to.html	10 Apr 2017 11:48:09 -0000
@@ -398,7 +398,7 @@ 
 
 <p>GCC 5 implements
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579">DR 1579</a>
-which means that in a function like:</p>
+which means that when compiling a function like:</p>
 
 <pre><code>
   X
@@ -409,17 +409,17 @@ 
   }
 </code></pre>
 
-<p>GCC will first attempt to construct the return value as if <code>y</code> 
-were an rvalue, and if that fails then it will try again for an lvalue
+<p>GCC first attempts to construct the return value as though <code>y</code> 
+were an rvalue, and if that fails then it tries again using an lvalue
 (all C++11 compilers already do this when returning a variable of the
-same type as the function returns, but now they are required to do it
+same type as the function returns, but now they are also required to do it
 when the types are not the same).
-This will change the constructor that gets called in some cases,
+This changes the constructor that gets called in some cases,
 for example it might now call <code>X(Y&amp;&amp;)</code> instead of
 <code>X(const Y&amp;)</code>.
 </p>
 <p>
-In most cases the only observable difference will be code that runs faster
+In most cases the only observable difference is code that runs faster
 (by moving instead of copying) but if it causes a problem the new behavior
 can be prevented by ensuring the compiler treats <code>y</code> as an lvalue,
 using <code>return X(y);</code> or
Index: htdocs/gcc-7/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.13
diff -u -r1.13 porting_to.html
--- htdocs/gcc-7/porting_to.html	6 Apr 2017 17:12:16 -0000	1.13
+++ htdocs/gcc-7/porting_to.html	10 Apr 2017 11:48:09 -0000
@@ -118,6 +118,39 @@ 
 with GCC 7 and some are compiled with older releases.
 </p>
 
+<h3 id="null-pointer-constants">Null pointer constants</h3>
+
+<p>
+When compiling as C++11 or later, GCC 7 follows the revised definition of a
+<em>null pointer constant</em>. This means conversions to pointers from other
+types of constant (such as character literals and boolean literals) are now
+rejected.
+</p>
+
+<pre><code>void* f() {
+  char* p = '\0';
+  return false;
+}
+</code></pre>
+
+      <blockquote><pre>
+<span class="boldred">error:</span> invalid conversion from <b>'char'</b> to <b>'char*'</b> [<span class="boldred">-fpermissive</span>]
+   char* p = <span class="boldred">'\0'</span>;
+             <span class="boldred">^~~~</span>
+<span class="boldred">error:</span> cannot convert <b>'bool'</b> to <b>'void*'</b> in return
+   return <span class="boldred">false</span>;
+          <span class="boldred">^~~~~</span>
+</pre></blockquote>
+
+<p>
+Such code should be fixed to use a valid null pointer constant such as
+<code>0</code> or <code>nullptr</code>. Care should be taken when fixing
+invalid uses of <code>'\0'</code> as a pointer, as it may not be clear whether
+the intention was to create a null pointer (<code>p = 0;</code>), to create an
+empty string (<code>p = "";</code>), or to write a null terminator to the
+string (<code>*p = '\0';</code>).
+</p>
+
 <h3 id="header-dep-changes">Header dependency changes</h3>
 
 <p>