On Wed, 17 Oct 2018, Richard Sandiford wrote: > > 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. > > Could you give pointers to the specific proposals/papers you mean?
They're generally reflector discussions rather than written up as papers, exploring the space of problems and solutions in various areas (including bignums and runtime introspection of types). I think the first message in those discussions is number 15529 <http://www.open-std.org/jtc1/sc22/wg14/15529> and then relevant discussions continue for much of the next 200 messages or so. > ...and here is that any size changes come only from changes in the > implementation-defined built-in sizeless types. The user can't define But then I think you still need to define in the standard edits something of what the type-compatibility rules are. > > Can these types be passed to variadic functions and named in va_arg? > > Again, I don't see anything to say they can't. > > Yes, this is allowed (and covered by the tests FWIW). How does that work with not knowing the size even at runtime? At least, this seems like another place where there would be special type compatibility considerations that need to be applied between caller and callee. > Except for bit-fields *and sizeless structures*, objects are > composed of contiguous sequences of one or more bytes, the number, > order, and encoding of which are either explicitly specified or > implementation-defined. > > TBH the possibility of a discontiguous representation was an early idea > that we've never actually used so far, so if that's a problem, we could > probably drop it. It just seemed to be a natural extension of the > principle that the layout is completely implementation-defined. If you have discontiguous representations, I don't see how "->" on structure pointers (or indeed unary "*") is supposed to work; disallowing discontiguous representations would seem to fit a lot more naturally with the C object model. -- Joseph S. Myers jos...@codesourcery.com
