Alexander Benikowski via llvm-dev
2017-Jul-14 09:55 UTC
[llvm-dev] Building aggregate types with dynamically sized elements
> > 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>
David Chisnall via llvm-dev
2017-Jul-14 10:03 UTC
[llvm-dev] Building aggregate types with dynamically sized elements
On 14 Jul 2017, at 10:55, Alexander Benikowski <sebal007 at googlemail.com> wrote:> >> 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.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. David
Christer Swahn via llvm-dev
2017-Jul-14 10:19 UTC
[llvm-dev] Building aggregate types with dynamically sized elements
I would agree that such a capability is a questionable fit for C. 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. 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! Thanks 2017-07-14 12:03 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:> On 14 Jul 2017, at 10:55, Alexander Benikowski <sebal007 at googlemail.com> > wrote: > > > >> 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. > > 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. > > David > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/2bfcbd76/attachment.html>