theraven added a comment. This makes things worse for us. On CHERI, `[u]intptr_t` is a (`typedef` for a) built-in type that can hold a capability. Having `unw_word_t` be `uintptr_t` made LLVM's libunwind considerably easier to port than the HP unwinder would have been, because `uintptr_t` is a type that is able to hold either any integer-register type or a pointer, whereas neither `uint32_t` nor `uint64_t` is. This will be true for any architecture that supports any kind of fat-pointer representation.
What is the motivation for this change? It appears to be changing working code in such a way that removes future proofing. Replacing integer casts with `void*` casts and using `PRIxPTR` consistently would make life easier, though the use of `PRIxPTR` vs `PRIXPTR` seems inconsistent (as is the original use of `%x` vs `%X`. https://reviews.llvm.org/D39365 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
