MemoryLayout api

[Michael Zucchi]

On 22/1/20 1:58 am, Maurizio Cimadamore wrote:
> So, in a way, this is to make the layout API partially usable with 
> variable-sized structures. Think about classfile attributes e.g.
>
> RuntimeInvisibleParameterAnnotations_attribute {
>     u2 attribute_name_index;
>     u4 attribute_length;
>     u1 num_parameters;
>     {   u2         num_annotations;
>         annotation annotations[num_annotations];
>     } parameter_annotations[num_parameters];
> }
>
> These can have multiple sequences whose size is bound dynamically - 
> and not statically, right? 

But the only dynamic size you can have in a C struct is a flexible array 
member and that can only occur at the end of a structure.  And how that 
is interpreted is entirely up to the implementation: could be a specific 
length from some preceding integer, some calculated length (from 
anywhere), or often a sentinel-terminated sequence.  Are you going to 
support all those possibilities?

This seems like a lot of work to enable something that simply can't be 
done by a C compiler.  As an example a classfile isn't a structure but a 
file format, and to process a sequence such as the one above you need to 
write the business logic to iterate over it in parts that do fit into C 
types.  Making what amounts to a general (but necessarily limited) 
byte-stream (de)serialiser is kinda nifty but seems way out of scope for 
this project, surely?

For the moment I find MemoryLayout too high level so i'm ignoring it 
apart from the cases where they can't be avoided such as method handle 
creation where I dynamically create them from a signature. Any 
code-generator that creates a compound MemoryLayout has all the 
information it needs to not need to use it (and it can't just rely on 
the members defined since it must explicitly include the alignment and 
padding which might not confirm to the abi rules), and I don't require 
the metadata it encodes.