<div dir="ltr">I would agree that such a capability is a questionable fit for C.<div><br></div><div>However as others point out I think it depends on the language in question. In this case the language has runtime information about the array lengths and enforces the bounds strictly. The language's semantics for these aggregate, occasionally dynamically sized types I think are good; my problem is how best to map it onto LLVMs type model.</div><div><br></div><div>My concern as I said is about portability and alignment, if I roll my own type layout and offset computations. Any advice regarding this is much appreciated!</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-14 12:03 GMT+02:00 David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14 Jul 2017, at 10:55, Alexander Benikowski <<a href="mailto:sebal007@googlemail.com">sebal007@googlemail.com</a>> wrote:<br>
><br>
>> Note: C does not support this.  GCC has an extension (variable length arrays in structs), but clang doesn’t support it and it’s a terrible idea.<br>
> It might be complex but it is not terrible. Depends on the language capabilities implementing it. Delphi for example allows exactly that and finalizes its records through RTTI which allows to automatically free up the memory.<br>
<br>
</span>The Pascal type system, unlike C, does not erase array lengths in various places, so doing the same thin in Pascal would be far less problematic than C.  That doesn’t alter the fact that it’s a terrible idea for C, where it encourages to error-prone code.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>