C++ VS2010静态代码分析错误？

好的，我很确定这是由于VisualStudio中的错误静态代码分析器造成的，但我认为更多的人关注这一点不会有什么坏处

我已经编写了自己的矢量样式容器集合。它们似乎工作正常，但我注意到Visual Studio静态代码分析器发出了以下警告：

警告C6386:缓冲区溢出：访问“参数1”，可写大小为“newspace*4”字节，但可能会写入“4194240”字节

上述警告出现在以下代码的最后一行memcpy上，并突出显示前面的所有行。这个特定向量类可以容纳的所有可能类型都是POD。mSpace包含向量中可用内存可以容纳的项目数，并对当前项目数进行mSize。mDynamic指向当前由向量管理的内存块

Bool Insert( UInt32 index, TYPE value, UInt32 count = 1 )
{
    if( index < mSize )
    {
        UInt32  newsize = mSize + count;

        if( newsize > mSpace )
        {
            UInt32  newspace = std::max( Align( newsize, 8 ), mSpace << 1 );
            TYPE*   ptr = new TYPE[ newspace ];

            if( ptr )
            {
                memcpy( ptr, mDynamic, index * sizeof( TYPE ));
                // The remainder of the code copies the second half of the
                // existing data and inserts the new values...

我一直看着这个，直到我的眼睛流血不止，几乎看不出分析仪为什么会产生这个警告。我在其他地方也看到过同样的警告，其值相当奇怪，为4194240，这就是为什么我认为这是分析仪中的另一个错误

---

有人能确认这是分析仪中的一个已知错误吗？对connect的快速搜索没有提供任何结果，或者我的代码中是否有一个明显的错误，我只是没有看到？

不确定它是否与警告相关，但您确实在这里有一个错误。如果mSize为2^32-1，则由于整数溢出，newsize将设置为0，这将导致缓冲区溢出。如果不检查结果是否在32位内，而对TYPE执行index*sizeof，则会出现类似的错误

---

更次要的是，但是您应该真正使用size\u t而不是UInt32，否则，如果您想编译到64位，您将收到关于与size不匹配的类型的警告memcpy将size\u t作为第三个参数，并且在64位窗口上size\u t是64位。

不确定它是否与警告相关，但此处确实存在错误。如果mSize为2^32-1，则由于整数溢出，newsize将设置为0，这将导致缓冲区溢出。如果不检查结果是否在32位内，而对TYPE执行index*sizeof，则会出现类似的错误

---

更次要的是，但是您应该真正使用size\u t而不是UInt32，否则如果您想编译到64位，您将收到关于与size不匹配的类型的警告memcpy将size\u t作为第三个参数，并且在64位窗口上size\u t是64位。

4194240是2^22-2^6。不确定这是否相关…在我看来，这是一个相当虚假的警告。。。警告是否仅在使用特定类型实例化时显示？比如，如果你在一个没有客户端的项目中隔离你的类，它会出现吗？也许你可以尝试通过另一个来运行你的代码……不，它会出现在很多不同的类型中。我尝试过其他几种不同的静态代码分析工具，但没有一个提到这段代码——这也表明这是一个VS2010错误。我还看到了针对完全不相关的代码段出现的警告-同样是魔法4194240值，因此我几乎已经将其视为不是我的问题。4194240是2^22-2^6。不确定这是否相关…在我看来，这是一个相当虚假的警告。。。警告是否仅在使用特定类型实例化时显示？比如，如果你在一个没有客户端的项目中隔离你的类，它会出现吗？也许你可以尝试通过另一个来运行你的代码……不，它会出现在很多不同的类型中。我尝试过其他几种不同的静态代码分析工具，但没有一个提到这段代码——这也表明这是一个VS2010错误。我还看到了针对完全不相关的代码段出现的警告-同样是magic 4194240的值，因此我基本上已经将其视为不是我的问题。实际上，早在mSize达到2^32-1之前，我就会遇到溢出错误。大概在mSize*sizeof TYPE达到2^32时。不过到那时我会有很多其他问题，比如没有任何内存留给代码；事实上，在WindowsXP上，在进程启动后很难分配一块大于700MB的内存。这一数字在Vista/7上有所增加，但仍远未达到32位地址空间的限制。至于64位，自从微软推出第一批64位编译器以来，我一直在构建Win64。使用尺码是我尽可能避免的事情。我已经修复了太多来自其他人的bug，他们将大小与int混合在一起，这带来了非常有趣的后果，主要是因为他们希望文件和网络连接能够在不同的体系结构之间神奇地工作。此外，64位类型的内存需求增加了一倍，我在这里不需要64位大小，而且64位指令在AMD64上加了前缀，这也不必要地增加了代码大小。事实上，我很长时间都会遇到溢出错误

---

前mSize命中2^32-1。大概在mSize*sizeof TYPE达到2^32时。不过到那时我会有很多其他问题，比如没有任何内存留给代码；事实上，在WindowsXP上，在进程启动后很难分配一块大于700MB的内存。这一数字在Vista/7上有所增加，但仍远未达到32位地址空间的限制。至于64位，自从微软推出第一批64位编译器以来，我一直在构建Win64。使用尺码是我尽可能避免的事情。我已经修复了太多来自其他人的bug，他们将大小与int混合在一起，这带来了非常有趣的后果，主要是因为他们希望文件和网络连接能够在不同的体系结构之间神奇地工作。再加上64位类型的内存需求翻倍，我在这里不需要64位大小，而且64位指令的前缀是AMD64，这也不必要地增加了代码大小。