More detail than I had intended on Layout description language.

[Angela Lin]

Some aspects I'd like to highlight from Tobi's email:

1. LDL/NFD, by default, should describe exact memory layout on the
execution platform. In particular:
- Fields must have explicitly specified width. So, if the LDL/NFD models a
C struct that contains a void*, the size of the void* has to be known
up-front.
- No automatic padding or alignment.
- Fields either have explicitly specified offset, or are laid out in the
order of specification.
- Native endian.

This implies that the descriptor for, say, a C struct, may not be portable
across all platforms. If the descriptor models a data structure that is
shared with a native library, then the descriptor is tied to the particular
native library binary. I think this is consistent with David's earlier
statement:
> So, since the Java-side behavior should be different, I think that
> the little language inputs
> (the output of the libclang-based tool) should be different
> depending on platform ? the
> offsets will need to be described in ways that make conform to
> Java?s expectations.

User-friendly descriptor options could certainly be added, as long as we
agree on the default behaviour.

2. Layouts should offer access to the raw field bits by value and
reference, without conversion to a Java type (primitive int, float, or
otherwise). We'd like to be able to pass a field to a library that knows
how to handle the non-Java data type, and we'd like to avoid marshalling
costs.

3. The descriptor should provide a way to specify how the raw field bits
should be interpreted as a Java entity. This could be as simple as casting
the field bits to a suitably sized Java integer type.

A more structured descriptor language does provide more flexibility for
doing the above.

Angela