[llvm-dev] Building aggregate types with dynamically sized elements

[Alexander Benikowski via llvm-dev]

>
> 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.

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.

2017-07-14 10:26 GMT+02:00 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org>:

> On 14 Jul 2017, at 09:12, Christer Swahn via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I'm looking into ways to represent complex aggregate types whose members
> and/or sub-members may be dynamically sized. This would conceptually
> correspond to a C struct containing other structs and arrays, and some of
> those arrays would have a length that is not known in compile time.
>
> 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.
>
> > LLVM IR allows me to do this for a top-level array (using 0 as its LLVM
> data type length and manually computing its needed allocation size).
> >
> > As far as I understand, if I want to represent structs containing
> dynamic arrays containing structs and so on, I will have to roll my own
> data size computation, element pointer computation and so on. This however
> seems to be a significant risk to portability and alignment handling.
> >
> > Does anyone here have any experience with similar use cases, or any
> advice on how to handle this?
>
> You will have to do this manually, via pointer casts of the results of
> GEPs.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/73ad6f16/attachment.html>