This SharedBuffer class is turning up in compiler errors for me related to stringop-overflow.

/usr/include/bits/string_fortified.h:34:33: error: writing 4 bytes into a region of size 0 [-Werror=stringop-overflow=]

https://parsley.mongodb.com/evergreen/mongodb_mongo_master_commit_queue_compile_and_run_unittests_fourth_group_patch_8dc909de71876a568e74c75d0a509f43e25b1c47_67b21a621dad740007b05da7_25_02_16_17_03_35/0/task?bookmarks=0,3243,3462,3463,3475,3533,3535,3829&selectedLineRange=L3462

The source line src/mongo/transport/message_compressor_manager_test.cpp:392:21 is a use of a SharedBuffer.

    auto badMessageBuffer = SharedBuffer::allocate(128);
    MsgData::View badMessage(badMessageBuffer.get());
    badMessage.setId(1);
    badMessage.setResponseToMsgId(0);
    badMessage.setOperation(dbCompressed);
    badMessage.setLen(128);

All of these 4 setters look to the compiler like stringop-overflow error.

This may be related to some UB issues in the implementation. I don't know.
I looked into the class and there are some unusual things going on and general things that could be improved about it. Some thoughts:

• swaps should be noexcept.

• Move operations must be noexcept. They aren't.

• use explicit(true) for unary conversion ctors instead of comments.

• UniqueBuffer shouldn't need to be predeclared before SharedBuffer.
  SharedBuffer has no reason to know what UniqueBuffer is.

• Assignment to `*this=....` in a constructor feels very dodgy, especially in a non-final class. We should be able to avoid this.

• Document the Holder class.

• Don't copy allocators in ctors. Take by value and std::move.

• allocator sizes are size_t, not uint32_t. No traits inform the users about the change of types, so this feels dangerous. The allocator is limited to 4GiB but not in a way that's apparent to user code. We should consider just upgrading it to size_t.

• The different classes in here have friendship but not documentation about why.
  The friendships seems like they are probably unneeded.

• Use of DataView should probably be avoided as unnecessary indirection.