FBString最大容量为多少？其max_size()接口实现是否存在设计缺陷？

结论 #

你的理解完全正确，这是FBString实现中不符合C++标准约定的一处瑕疵，但在实际工程场景中几乎不会产生可感知的影响，通常不会被归类为需要紧急修复的严重bug。

具体说明 #

• 你对MediumLarge结构的分析没有问题：FBString确实占用了capacity_字段的2个比特位存储字符串的分类标记（小/中/大类型），因此实际可表示的容量上限比size_t的最大值少2位，64位架构下最大可支持的容量为2^62 - 1，远小于std::numeric_limits<size_t>::max()对应的2^64 - 1。
• 按照C++标准对容器max_size()接口的定义，该接口需要返回容器理论上可支持的最大元素数量，FBString当前直接返回size_t最大值的实现确实不符合这个要求，属于实现层面的疏漏。
• 从实际使用角度看，这个问题没有业务影响：当前主流64位操作系统给单进程开放的用户态虚拟地址空间普遍远小于2^62字节，比如x86_64架构的Linux系统默认用户态地址空间仅为2^48字节，根本不可能申请到接近2^62字节的连续内存，几乎不会有业务场景会触发这个不一致的问题。
• 如果要修复这个问题成本极低，只需要修改max_size()的实现，返回(std::numeric_limits<size_t>::max() >> 2)即可，只是因为没有实际的使用需求，社区一直没有做这个改动。

对应的MediumLarge实现代码如下：

struct MediumLarge {
  Char* data_;
  size_t size_;
  size_t capacity_;

  size_t capacity() const {
    return kIsLittleEndian ? capacity_ & capacityExtractMask : capacity_ >> 2;
  }

  void setCapacity(size_t cap, Category cat) {
    capacity_ = kIsLittleEndian
        ? cap | (static_cast<size_t>(cat) << kCategoryShift)
        : (cap << 2) | static_cast<size_t>(cat);
  }
};

内容的提问来源于stack exchange，提问作者konchy