[Splitting this off to not derail the review] On 14/03/2020 00:45, Greg Clayton via Phabricator wrote: > labath wrote: >> This will return a dangling pointer as Envp is a temporary object. It's >> intended to be used to pass the environment object to execve-like function. >> The current "state of the art" is to ConstStringify all temporary strings >> that go out of the SB api. (Though I think we should start using >> std::string). >> >> Also, constructing the Envp object just to fetch a single string out of it >> is pretty expensive. You can fetch the desired result from the Environment >> object directly. >> >> Putting it all together, this kind of an API would be implemented via >> something like: >> ``` >> if (idx >= m_opaque_up->size()) >> return nullptr; >> return ConstString(Environment::compose(*std::next(m_opaque_up.begin(), >> idx)).AsCString(); >> ``` >> >> ... but I am not sure this is really the right api. More on that in a >> separate comment. > Yes, any C strings returned from the SB API should use > ConstString(cstr).AsCString() as the ConstString puts the string into a > string pool and there is no need to clients to destruct the string or take > ownership. > > No STL in the SB API please, so no std::string. std::string isn't stable on > all platforms and competing C++ runtimes on different platforms can cause > problems. If we need string ownership, we can introduce SBString as a class.
What do you exactly mean by "not stable"? All major C++ standard libraries I have knowledge of (libstdc++, libc++, msvc stl) take abi stability very seriously (more seriously than we do for SB api). I can see how returning std::strings would be a problem if one builds liblldb with one c++ library (say libstdc++) and then tries to build the dependant program with libc++ (are those the competing runtimes you mentioned?), but.. is that something we have signed up to support? The main reason I am even thinking about this is because swig already knows how to map common stl types onto native types of other languages. This is particularly important if we are going to have multiple scripting languages, as we wouldn't need to redo the mapping for each script language and each stl-like class we have (e.g. all SBXXXLists) pl _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
