This is an archive of the discontinued LLVM Phabricator instance.

Improve optional formatter
ClosedPublic

Authored by wallace on Nov 23 2021, 9:19 AM.

Details

Summary

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.

Diff Detail

Event Timeline

wallace requested review of this revision.Nov 23 2021, 9:19 AM
wallace created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2021, 9:19 AM
labath accepted this revision.Nov 23 2021, 9:54 AM

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.

This revision is now accepted and ready to land.Nov 23 2021, 9:54 AM

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?

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

Cool, thanks.

lldb/examples/synthetic/gnu_libstdcpp.py
24

You are correct. However, _checking_ whether something is true is normally implemented as != 0.
This doesn't make a difference for the normal case, but in the "corrupted" case it might be a bit confusing that the program will report the optional object as "engaged", but we will say it's empty. It's not a big deal though.

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).

wallace updated this revision to Diff 389260.Nov 23 2021, 10:52 AM

fix the issue when both formatters run together and apply labath's suggestion

This revision was automatically updated to reflect the committed changes.