On Windows at least, llvm-strings was crashing if it encountered bytes that mapped to negative chars, as it was passing these into std::isgraph and std::isblank functions, resulting in undefined behaviour. On debug builds using MSVC, these functions verfiy that the value passed in is representable as an unsigned char. Since the char is promoted to an int, a value greater than 127 would turn into a negative integer value, and fail the check. Using the llvm::isPrint function is sufficient to solve the issue.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/llvm/ADT/StringRef.h | ||
---|---|---|
93–97 | Not sure if this is a good thing to do. If you do, you probably should do the same for StringRef::StringRef(const char *Str) and other functions? But isn't that a bit too much? |
include/llvm/ADT/StringRef.h | ||
---|---|---|
93–97 |
IMO StringRef::StringRef(const char *Str) should only be used for string literals. Same with StringRef::withNullAsEmpty(). |
tools/llvm-strings/llvm-strings.cpp | ||
---|---|---|
84 | Could we just use something like if (isPrint(*P) || *P == '\t') to avoid the issue? std::isgraph has other issues (see r338034). |
tools/llvm-strings/llvm-strings.cpp | ||
---|---|---|
84 | Yes, I think we can, and that then solves the need for the new StringRef constructor. I'll update. |
Remove unsigned char StringRef constructor, use llvm::isPrint, and improve test to show that the negative character is not printed.
LGTM for what that's worth, but I'll leave it for those who commented earlier to do the final approval.
Not sure if this is a good thing to do. If you do, you probably should do the same for StringRef::StringRef(const char *Str) and other functions? But isn't that a bit too much?