This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] doc fix for c/71560 - union compound literal initializes wrong union field


On 07/01/2016 05:56 PM, Martin Sebor wrote:
The bug points out a couple of conformance problems in the GCC
manual where is discusses compound literals and casts to unions
and says that a compound literal is equivalent to a cast.  It
isn't because a compound literal is an lvalue but a cast yields
an rvalue.

The attached patch corrects this error and adds some clarifying
text to illustrate the differences.

This looks OK modulo some markup problems.

@@ -1905,18 +1906,23 @@ such an initializer, as shown here:
 char **foo = (char *[]) @{ "x", "y", "z" @};
 @end smallexample

-Compound literals for scalar types and union types are
-also allowed, but then the compound literal is equivalent
-to a cast.
+Compound literals for scalar types and union types are also allowed.  In
+the following example the variable @var{i} is initialized to the value

s/@var/@code/

(@var is for metasyntactic variables, not program variables.)

@@ -1934,22 +1940,21 @@ static int z[] = @{1, 0, 0@};

 In C, a compound literal designates an unnamed object with static or
 automatic storage duration.  In C++, a compound literal designates a
-temporary object, which only lives until the end of its
-full-expression.  As a result, well-defined C code that takes the
-address of a subobject of a compound literal can be undefined in C++,
-so the C++ compiler rejects the conversion of a temporary array to a pointer.
-For instance, if the array compound literal example above appeared
-inside a function, any subsequent use of @samp{foo} in C++ has
-undefined behavior because the lifetime of the array ends after the
-declaration of @samp{foo}.
+temporary object that only lives until the end of its full-expression.
+As a result, well-defined C code that takes the address of a subobject
+of a compound literal can be undefined in C++, so G++ rejects
+the conversion of a temporary array to a pointer.  For instance, if
+the array compound literal example above appeared inside a function,
+any subsequent use of @samp{foo} in C++ would have undefined behavior
+because the lifetime of the array ends after the declaration of @samp{foo}.

-As an optimization, the C++ compiler sometimes gives array compound
-literals longer lifetimes: when the array either appears outside a
-function or has const-qualified type.  If @samp{foo} and its
-initializer had elements of @samp{char *const} type rather than
-@samp{char *}, or if @samp{foo} were a global variable, the array
-would have static storage duration.  But it is probably safest just to
-avoid the use of array compound literals in code compiled as C++.
+As an optimization, G++ sometimes gives array compound literals longer
+lifetimes: when the array either appears outside a function or has
+a const-qualified type.  If @samp{foo} and its initializer had elements
+of type @samp{char *const} rather than @samp{char *}, or if @samp{foo}
+were a global variable, the array would have static storage duration.
+But it is probably safest just to avoid the use of array compound
+literals in C++ code compiled.

I think it would be more appropriate to use @code rather than @samp markup throughout this discussion, since foo, char*, etc are "entire syntactic tokens", per the texinfo manual.

-Sandra the nit-picky


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]