Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 16 Oct 2018, Richard Sandiford wrote:

> > as Joseph pointed out, there are some related discussions
> > on the WG14 reflector. How a about moving the discussion
> > there?
> 
> The idea was to get a feel for what would be acceptable to GCC
> maintainers.  When Arm presented an extension of P0214 to support SVE
> at the last C++ committee meeting, using this sizeless type extension
> as a possible way of providing the underlying vector types, the feeling
> seemed to be that it wouldn't be considered unless it had already been
> proven in compilers.

But as shown in the related discussions, there are other possible features 
that might also involve non-VLA types whose size is not a compile-time 
constant.  And so it's necessary to work with the people interested in 
those features in order to clarify what the underlying concepts ought to 
look like to support different such features.

> I think it is for some poople though.  If the vectors don't decay to
> pointers, they're moe akin to a VLA wrapped in a structure rather than
> a stand-alone VLA.  There is a GNU extension for that, e.g.:
> 
>   int
>   f (int n)
>   {
>     struct s {
>       int x[n];
>     } foo;
>     return sizeof (foo.x);
>   }
> 
> But even though clang supports VLAs (of course), it rejects the
> above with:
> 
>   error: fields must have a constant size: 'variable length array in structure' extension will never be supported
> 
> This gives a strong impression that wrapping a VLA type like this
> is a bridge too far for some :-)  The message makes it clear that's
> a case of "don't even bother asking".

What are the clang concerns about VLAs in structs that are the reason for 
not supporting them?  How do the sizeless structs with sizeless members in 
your proposal avoid those concerns about the definition of VLAs in 
structs?

> The problem isn't so much that the size is only known at runtime,
> but that the size isn't necessarily invariant, and the size of an
> object doesn't carry the size information with it.
> 
> This means you can't tell what size a given object is, even at runtime.

How then is e.g. passing a pointer to such a struct (containing such 
unknown-size members) to another function supposed to work?  Or is there 
something in your proposed standard text edits that would disallow passing 
such a pointer, or disallow using "->" with it to access members?

> All you can tell is what size the object would be if you created it
> from scratch.  E.g.:
> 
>   svint8_t *ptr;  // pointer to variable-length vector type
> 
>   void thread1 (void)
>   {
>     svint8_t local;
>     *ptr = &local;
>     ...run for a long time...
>   }
> 
>   void thread2 (void)
>   {
>     ... sizeof (*ptr); ...;
>   }
> 
> If thread1 and thread2 have different vector lengths, thread2 has no way
> of knowing what size *ptr is.
> 
> Of course, thread2 can't validly use *ptr if it has wider vectors than
> thread1, but if we resort to saying "undefined behavior" for the above,
> then it becomes difficult to define when the size actually is defined.

What in your standard text edits serves to make that undefined?  
Generally, what in those edits serves to say when conversions involving 
such types, or pointers thereto, or accesses through compatible types in 
different places, are or are not defined?

In standard C, for example, we have for VLAs 6.7.6.2#6, "If the two array 
types are used in a context which requires them to be compatible, it is 
undefined behavior if the two size specifiers evaluate to unequal 
values.".  What is the analogue of this for sizeless types?  Since unlike 
VLAs you're allowing these types, and sizeless structs containing them, to 
be passed by value, assigned, etc., you need something like that to 
determine whether assignment, conditional expression, function argument 
passing, function return, access via a pointer, etc., are valid.

Can these types be used with _Atomic?  I don't see anything to say they 
can't.

Can these types be passed to variadic functions and named in va_arg?  
Again, I don't see anything to say they can't.

Can you have file-scope, and so static-storage-duration, compound literals 
with these types?  You're allowing compound literals with these types, and 
what you have disallowing objects with these types with non-automatic 
storage duration seems to be specific to the case of "an identifier for an 
object".

I don't see any change proposed to 6.2.6.1#2 corresponding to what you say 
elsewhere about discontiguous representations of sizeless structures.

> But do you have any feel for whether this would ever be acceptable
> in C++?  One of the main requirements for this was that it needs
> to work in both C and C++, with the same ABI representation.
> I thought VLAs were added to an early draft of C++14 and then
> removed before it was published.  They weren't added back for C++17,
> and I'd seen other proposals about classes having a "sizeof field"
> instead (i.e. the type would carry the size information with it,
> which we don't want).  So the prospects didn't look good.

What were the C++ concerns with VLAs, and how do the variable-size types 
in this proposal avoid those concerns?

-- 
Joseph S. Myers
joseph@codesourcery.com