Peter Dimov

We have a separate macro for C strings, which is `BOOST_TEST_CSTR_EQ`. `BOOST_TEST_EQ` tests for equality using `==`, which for `char*` compares addresses, so the output also prints addresses to match...

Yes, I understand that, but how are we supposed to distinguish the two cases? In general we have no idea what `==` does. We could special-case `std::string`, I suppose, and...

Not entirely unrelated; when the test fails the values need to tell us why. > the special case is comparing two pointers and the rest can be assumed to operate...

Check whether your `pyconfig.h` file contains `#define copysign _copysign`. I can't find such a line in my Python 3.9 installation, only a comment in `pymath.h` about it, but it might...

The easiest fix then is to upgrade to a more recent Python version, one that no longer has the `#define`. I'm not sure what we can do on the Boost...

`#define HAVE_COPYSIGN 1` in pyconfig.h just means that the compiler has a `copysign` function, which Python can use without needing to redefine `copysign` to `_copysign`.

The current implementation is in `boost/core/bit.hpp`.

I don't think `padding_cast`, however specified, belongs here. I'll make use of `__builtin_bit_cast` for `constexpr` reasons though, because I've already done some `constexpr` work on the rest of `bit.hpp`.

What is the intended use of `padding_cast`?

It's a request to add `pilfer` to Core. `pilfer` currently exists in Boost.JSON detail, and has been proposed by me in [P0308](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html). That'd actually be a legitimate addition to Core,...