为什么使用这个 POD 结构作为基类会很危险？

发布于 2024-11-30 09:02:10 字数 266 浏览 1 评论 0原文

我和一位同事进行了这样的对话，结果很有趣。假设我们有以下 POD 类

struct A { 
  void clear() { memset(this, 0, sizeof(A)); } 

  int age; 
  char type; 
};

clear 旨在清除所有成员，设置为 0 （按字节）。如果我们使用 A 作为基类会出现什么问题？这里有一个微妙的错误来源。

原文

I had this conversation with a colleague, and it turned out to be interesting. Say we have the following POD class

struct A { 
  void clear() { memset(this, 0, sizeof(A)); } 

  int age; 
  char type; 
};

clear is intended to clear all members, setting to 0 (byte wise). What could go wrong if we use A as a base class? There's a subtle source for bugs here.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

烟─花易冷 2024-12-07 09:02:10

编译器可能会向 A 添加填充字节。因此 sizeof(A) 超出了 char 类型（直到填充结束）。但是，在继承的情况下，编译器可能不会添加填充字节。因此对memset的调用将覆盖子类的部分内容。

回复收藏 0 原文

兔小萌 2024-12-07 09:02:10

除了其他注释之外，sizeof 是一个编译时运算符，因此 clear() 不会将派生类添加的任何成员清零（除非由于填充而指出）怪异）。

这并没有什么真正“微妙”的地方。在 C++ 中使用 memset 是一件可怕的事情。在极少数情况下，您确实可以用零填充内存并期望正常的行为，和您确实需要用零填充内存，和通过以下方式对所有内容进行零初始化：初始化列表文明的方式在某种程度上是不可接受的，请使用 std::fill 代替。

回复收藏 0 原文

那请放手 2024-12-07 09:02:10

理论上，编译器可以以不同的方式布局基类。 C++03 §10 第 5 段说：

基类子对象的布局 (3.7) 可能与相同类型的最派生对象的布局不同。

作为StackedCrooked 提到，当基类 A 作为自己的对象存在时，编译器在基类 A 的末尾添加填充可能会发生这种情况，但编译器可能不会当它是基类时添加该填充。这将导致 A::clear() 覆盖子类成员的前几个字节。

然而在实践中，我无法使用 GCC 或 Visual Studio 2008 来实现这一点。使用此测试：

struct A
{
  void clear() { memset(this, 0, sizeof(A)); }

  int age;
  char type;
};

struct B : public A
{
  char x;
};

int main(void)
{
  B b;
  printf("%d %d %d\n", sizeof(A), sizeof(B), ((char*)&b.x - (char*)&b));
  b.x = 3;
  b.clear();
  printf("%d\n", b.x);

  return 0;
}

并将 A、B 或两者修改为“打包”（带有 #pragma pack 在 VS 和 __attribute__((packed)) in GCC)，在任何情况下我都无法覆盖 bx 。优化已启用。打印的尺寸/偏移量的 3 个值始终为 8/12/8、8/9/8 或 5/6/5。

In theory, the compiler can lay out base classes differently. C++03 §10 paragraph 5 says:

A base class subobject might have a layout (3.7) different from the layout of a most derived object of the same type.

As StackedCrooked mentioned, this might happen by the compiler adding padding to the end of the base class A when it exists as its own object, but the compiler might not add that padding when it's a base class. This would cause A::clear() to overwrite the first few bytes of the members of the subclass.

However in practice, I have not been able to get this to happen with either GCC or Visual Studio 2008. Using this test:

struct A
{
  void clear() { memset(this, 0, sizeof(A)); }

  int age;
  char type;
};

struct B : public A
{
  char x;
};

int main(void)
{
  B b;
  printf("%d %d %d\n", sizeof(A), sizeof(B), ((char*)&b.x - (char*)&b));
  b.x = 3;
  b.clear();
  printf("%d\n", b.x);

  return 0;
}

And modifying A, B, or both to be 'packed' (with #pragma pack in VS and __attribute__((packed)) in GCC), I couldn't get b.x to be overwritten in any case. Optimizations were enabled. The 3 values printed for the sizes/offsets were always 8/12/8, 8/9/8, or 5/6/5.

回复收藏 0 原文