<div dir="ltr">Since Reid pointed me at this thread, I thought I would provide some hopefully useful ideas.<br><div class="gmail_extra"><br><div class="gmail_quote">First, a clarification: we have a large number of users that are parsing command line options with LLVM used as a library. They have requirements to not leak memory in addition to not having a good way to persist the strings being parsed. I'm very opposed to any direction which assumes that the parsed flags are memory managed externally to LLVM because it isn't true today and would regress a large amount of customer code.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">It feels like there is a reasonably simple, reasonably clear strategy here:</div><div class="gmail_quote"><br></div><div class="gmail_quote">1) flags don't own their memory, and point at a global constant on construction</div>
<div class="gmail_quote">2) parsing flags allocates memory for new values (preferably on LLVMContext), and sets the flags to point at these new things</div><div class="gmail_quote">3) when shutting down an LLVMContext, we reset the flags to their global constants</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Without doing something to take ownership of the memory when parsing flags, this change will break a very large number of users of LLVM, so I don't think there is going to be a significantly simpler solution here.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">The only thing seriously broken about the above is that users of LLVMContext in multiple threads cannot parse commandline flags. That's already true though, so I don't worry about *this* breaking existing users.</div>
</div></div>