Prevent crashing like llvm.org/pr37054
Details
- Reviewers
ki.stfu abidh sgraenitz jingham - Commits
- rG2a4c1f3e5b28: [lldb-mi] Check raw pointers before passing them to std::string ctor/assignment
rLLDB354798: [lldb-mi] Check raw pointers before passing them to std::string ctor/assignment
rL354798: [lldb-mi] Check raw pointers before passing them to std::string ctor/assignment
Diff Detail
- Repository
- rL LLVM
Event Timeline
Thanks for the review!
MIDataTypes.h | ||
---|---|---|
67 ↗ | (On Diff #186892) | Unfortunately no, with Optional<T*> getValueOr doesn't have the constraint that alternative value is not nullptr. |
71 ↗ | (On Diff #186892) | It is easier to read: const char *pFileName = GetDereferenceable(fileSpec.GetFilename()).Or(*pUnknown); vs const char *pFileName = fileSpec.GetFilename(); pFileName = (pFileName != nullptr) ? pFileName : pUnknown; isn't it? |
In the future please include context with the diff (-U9999 should do the trick), it makes reviewing a lot easier.
Have you considered wrapping raw strings in llvm's StringRefs? It looks like lldb-mi is already using some ADT classes from llvm.
Unfortunately we cannot use those in the SB interface, but they're a lot safer. They have a .str() which does the right thing and returns an empty string when the raw string is a nullptr. Personally I would very much prefer that over the This.or(That) pattern, but if you really wanted that you could have an Optional<StringRef> and do getValueOr() as Shafik suggested.
Thank you for mentioning StringRef, you gave me the idea to keep pointers check inside the CMIUtilString to obviate undefined behavior. This is the best place to do it, however, a caller still should examine pointers he passes to CMIUtilString::Format as the ellipsis parameter.
Good initiative to fix potential nullptr assignments to std::string.
So Format() and Printf() don't handle nullptr arguments already?
+1 in general (but it may be a bigger effort)
unittests/tools/lldb-mi/CMakeLists.txt | ||
---|---|---|
1 ↗ | (On Diff #187153) | LLDB_PROJECT_ROOT is rarely used, maybe prefer LLDB_SOURCE_DIR? |
unittests/tools/lldb-mi/utils/CMakeLists.txt | ||
3 ↗ | (On Diff #187153) | Nice workaround for not having a library target at hand for linking! |
unittests/tools/lldb-mi/utils/StringTest.cpp | ||
1 ↗ | (On Diff #187153) | update name |
Thanks for the review!
So Format() and Printf() don't handle nullptr arguments already?
They just forward arguments to vsprintf/vsnprintf. Otherwise, the would have to do twice the work parsing format string.
+1 in general (but it may be a bigger effort)
Since lldb-mi has its own wrapper for strings, we would have a conversion const char* -> StringRef -> CMIUtilString everywhere. This looks redundant to me and it is easy to forget converting a result of SB class's function to the StringRef.
The lldb-mi bits look ok to me.
tools/lldb-mi/MIUtilString.h | ||
---|---|---|
36 ↗ | (On Diff #187613) | May be spurious new line |
lldb/trunk/unittests/tools/lldb-mi/utils/CMakeLists.txt | ||
---|---|---|
12 | Just wanted to let you know that using $<TARGET_OBJECTS:...> in anything other than add_library and add_executable wasn't added until cmake 3.9, so I'm unable to configure lldb using the officially supported cmake 3.4.3 version. Btw, I use cmake 3.4.3 locally so I don't unintentionally use new unsupported features to the clang/llvm cmake files. |
lldb/trunk/unittests/tools/lldb-mi/utils/CMakeLists.txt | ||
---|---|---|
12 | I don't have all the various version installed, so I was trying to figure out which version by looking at the online docs. If 3.6.2 works, then it changed somewhere between 3.4.3 and 3.6.2, so I guess you can just use >= 3.6.2 for your test. Thanks again for looking into this. |
Just wanted to let you know that using $<TARGET_OBJECTS:...> in anything other than add_library and add_executable wasn't added until cmake 3.9, so I'm unable to configure lldb using the officially supported cmake 3.4.3 version.
Btw, I use cmake 3.4.3 locally so I don't unintentionally use new unsupported features to the clang/llvm cmake files.