DavidSpickett wrote: > If I understand correctly, both @jasonmolenda and @DavidSpickett are fine > with the SBStringList approach
I am suggesting that you could make such an argument but because I don't know enough about the existing SB types, I am not making it for you. Ideally we'd settle this by comparing: * What you have suggested already * The best representation using existing SB types * The best representation if we added some amount of new SB types I trust @medismailben more than myself to have ideas for the latter 2. Then looking at it for: * Usability / complexity * Fitting in, or not, with the other APIs If this weren't something in a public API I would not care at all, or if it was under some strange name rather than the perfect name for this functionality. To be honest that's the main problem I have, that the most obvious name would also be the one with the footguns. Then again, we have plenty of obviously named APIs with footguns so it's not like we haven't compromised before, but I prefer to compromise intentionally. Side idea: you could write a "unit test" that starts a process using the internal C++ API and maybe that will use the packets? That at least would delay the API question. https://github.com/llvm/llvm-project/pull/172026 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
