As suggested by @labath in https://reviews.llvm.org/D114403, we should
make the formatter more resilient to corrupted data. The Libcxx version
explicitly checks for engaged = 1, so we can do that as well for safety.
Details
- Reviewers
labath - Commits
- rG4ba5da8e3d38: Improve optional formatter
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I didn't realize that _M_engaged has type bool. That means the max value this could have is 255, which isn't nearly as bad as 0xffffffff. Nonetheless, this is a good change.
That said, I'm more worried about the strange interactions between libc++ and libstdc++ formatters I reported.
lldb/examples/synthetic/gnu_libstdcpp.py | ||
---|---|---|
24 | I'd use != 0, as matches what the actual implementation would do in this case. |
That said, I'm more worried about the strange interactions between libc++ and libstdc++ formatters I reported.
yes, I'm trying to install libc++ on my machine now
lldb/examples/synthetic/gnu_libstdcpp.py | ||
---|---|---|
24 | If that's true, then I'd need to update the libcxx formatter. My understanding is that setting something to true is always compiled as set to 1, or am I wrong? |
Cool, thanks.
lldb/examples/synthetic/gnu_libstdcpp.py | ||
---|---|---|
24 | You are correct. However, _checking_ whether something is true is normally implemented as != 0. I also wouldn't say you need to change the libc++ formatter too (though I won't stop you from doing it). If you really care about keeping the two in sync, I'd recommend making a unified implementation for the two (that might also probably fix the ordering problem). |
I'd use != 0, as matches what the actual implementation would do in this case.