[PATCH] Allow for the use of StringRef command line options instead of cl::opt<std::string>

[Reid Kleckner]

If CommandLine owns the strings, then why not just use cl::opt<std::string>?


On Thu, Aug 15, 2013 at 4:56 PM, Puyan Lotfi <plotfi at apple.com> wrote:

>
> This sounds like a workable compromise.
> To avoid leaking how about a CommandLine.cpp handled string pool that
> allocates copies on demand (specified maybe by an optional flag to
> ParseCommandLineOptions/ParseEnvironmentOptions) but also has the option of
> flushing/deallocating the pool?
>
> -Puyan
>
> On Aug 15, 2013, at 1:47 PM, Chris Lattner <clattner at apple.com> wrote:
>
> >
> > On Aug 14, 2013, at 4:06 PM, Puyan Lotfi <plotfi at apple.com> wrote:
> >
> >> Oh wow. I see that.
> >>
> >> I am not completely sure how the char* arrays would get handled this
> way.
> >> I did not make any clang modifications in this patch (although since
> clang is using the cl library it is affected) but I noticed that the use of
> cl:: in the llvm source tree made use of global cl::opt variables that
> specify the opt type.
> >> I don’t see that in the files handling the -mllvm options; I’ll have to
> look at the CommandLine.cpp code a little more closely to be sure in this
> case that the char*’s aren’t being implicitly put into StringRefs that
> might have their data pointers deallocated after
> cl::ParseCommandLineOptions() is called.
> >
> > After thinking about it for a bit, how about we go with this approach:
> >
> > 1. Document ParseCommandLineOptions/ParseEnvironmentOptions to only work
> with strings that live forever in CommandLine.h
> > 2. Change clang to leak (or store globally) the strings that are
> affected.
> >
> > I don't think it is worth designing a context system or anything like
> that to handle this case.
> >
> > -Chris
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130815/490da181/attachment.html>