[Lldb-commits] [PATCH] Add SBArgs to the public interface

[Zachary Turner]

In http://reviews.llvm.org/D8265#139340, @clayborg wrote:

> I don't want the API if we aren't going to use it in our API.
>
> If we do find a use for it we will need to returns "const char *" objects and state that the "const char *" values that are returned are only valid while for the lifetime of the SBArgs object. Then all std::string values turn into "const char *" in your API. Also, if you find a use for SBArgs somewhere you can't remove or change any existing API, you can only add functions. SBArgs could be returned from SBLaunchInfo, and the arguments could be set using an SBArgs (again, don't remove or change anything).
>
> The other reason I would rather not expose this is it opens up all sorts of question and possibilities of wether people are going to expect arguments to be expanded just like a shell? Which shell will it emulate? And all these questions we have been mulling over internally in LLDB.


It sounds like there's at least some consensus that there is *potential use* for it.  You mention SBLaunchInfo, and Jim mentioned SBCommandInterpreter::HandleCommand.  But is it necessary for me to add those now?  It seems like someone else could do that when they're ready to use SBLaunchInfo with an SBArgs, or when they're ready to build up an args and use HandleCommand.

I don't think anyone will be confused about shell emultaion.  Args -- and hence SBArgs -- have nothing to do with shell expansion.  If they're confused about SBArgs, then they're also confused about Args, because SBArgs is by definition just a wrapper around it.

Either way, I'm very strongly opposed to just saying "this is untestable unless we find another use for it a well".  That's not a realistic solution.  I don't think that's what you're saying, just wanted to make sure my opinion is clear.  So I guess the only realistic options I see are:

1. Add it to the SB API based on discussions of potential uses, and add tests.
2. C++ based unit tests.

If everyone is in agreement that we should not add things to the SB API just for tests, then we're going to have to do #2 someday anyway, because we can't add everything to the SB API.  So if 2 is the only option left, should I just go ahead and do it?

Once it's done, someone will need to get it integrated into the Xcode build, because tests that nobody runs aren't very helpful.


http://reviews.llvm.org/D8265

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/