c++ buffer overrun warning error C6386

[denver2020]

Hi all

The program below executes OK but getting one warning C6386 as shown below:
"warning C6386: Buffer overrun while writing to 'df.m_Dats': the writable size is '(unsigned __int64 size_t)*32' bytes, but '64' bytes might be written."
Any idea how to fix this? Is this vs2019 compiler bug and a known issue?

                std::map< uint32_t, const NTDraw * > uidToDraw;
                
                struct NTDraw
               {
	             NTDraw *				m_Parent;
	             NTQuad				m_Rot;		
	             NTVector				m_Trans;
	             std::vector< NTDraw * >	m_Child;
	             const uint32_t			m_UID;
	             static uint32_t			s_NextUID;

	             NTDraw() : m_Parent( NULL ), m_Trans( 0.0f, 0.0f, 0.0f ), m_UID( s_NextUID++ ) {}
	             NTDraw( const NTQuad &rot ) : m_Parent( NULL ), m_Rot( rot ), m_Trans( 0.0f, 0.0f, 0.0f ), m_UID( s_NextUID++ ) {}
                };

                struct Data
		{
			uint32_t		m_UID;			
		};
		
		struct Dataframe
		{
			Data *		m_Dats;
			uint32_t	m_NumDats;
		};
                Dataframe* m_Dataframes;
                uint32_t	m_NumDataframes;

                m_NumDataframes = DataFrames;
	        m_Dataframes = new Dataframe[ DataFrames ];
	        uint32_t dfidx = 0;
	        for ( uint32_t f=0;f<NumFrames;f++ )
	        {
                  Dataframe df;
		  df.m_Dats = new Data[ uidToDraw.size() ];
		  df.m_NumDats = (uint32_t)uidToDraw.size();
		  uint32_t keyid = 0;
		  for ( auto ti = uidToDraw.begin(); ti != uidToDraw.end(); ++ti )
		 {
			Data frame;
			frame.m_UID = ti->first;
			df.m_Dats[ dataidx++ ] = frame;
		 }
                m_Dataframes[dfidx++] = df;
               }

[Ganado]

I doubt it's a vs2019 compiler bug, especially without more evidence. <Edit: As seeplus mentioned, sometimes intellisense can show errors, and it may be strict or give false positives, but it still might point to a possible improvement.>

You need to show a minimal reproducible example.

The following uses your code verbatim, but produces no warnings at warning level 4:

#include <cstdint>
#include <map>

using std::uint32_t;

using UID = int;

struct Data {
	UID m_UID;
};

struct Key {
	Key& operator=(const Data& data)
	{
		return *this;
	}
};

struct Dataframe {
	Key* m_Dats;
	uint32_t m_NumDats;
};

int main()
{
	int dataidx = 0;
	std::map<UID, Data> uidToDraw;
	uidToDraw[0] = { 0 };

	//////////////////

	Dataframe df;
	df.m_Dats = new Key[uidToDraw.size()];
	df.m_NumDats = (uint32_t)uidToDraw.size();
	uint32_t keyid = 0;
	for (auto ti = uidToDraw.begin(); ti != uidToDraw.end(); ++ti)
	{
		Data frame;
		frame.m_UID = ti->first;
		df.m_Dats[dataidx++] = frame;
	}

	////////////////////
}

If I had to guess? It's that cast to (uint32_t) from size_t (64-bit). Or, it's complaining about how dataidx is only 32-bit.

[seeplus]

Is this a build warning or an intellisense warning?

[denver2020]

I was Running Code Analysis for C/C++ from VS2019 and ended up with this warning message, though my program executes OK. i am trying to figure out what went wrong in my code. Have updated above code and warning message occured at line 27: df.m_Dats[ dataidx++ ] = frame;

[AbstractionAnon]

To make any kind of intelligent guess at what' might be the problem, you should include the following in your code snippet:
- Declaration of Dataframe.
- Declaration of Key
- Declaration of uidToDraw
- Declaration of Data

[denver2020]

I have added those declarations in the code above. Please check it.

[salem c]

Still a rubbish attempt at http://sscce.org/

for ( uint32_t f=0;f<NumFrames;f++ )
{
    df.m_Dats = new Data[ uidToDraw.size() ];
    for ( auto ti = uidToDraw.begin(); ti != uidToDraw.end(); ++ti )
    {
        df.m_Dats[ dataidx++ ] = frame;
    }
}

You don't reset dataidx back to zero for your second pass through the f loop, so your second round of the ti loop uses a very non-zero dataidx value and keeps on incrementing from there on.

But how would we know, you've never shown how dataidx is declared or initialised.

Also, to stop your code looking like it's been dragged through a hedge, only use spaces for indentation (most modern editors deal with indentation very well).
A heady mix of spaces and tabs is a mess when posted.

> The program below executes OK
Sure it does.
But the very nature of "undefined behaviour" necessarily includes "doing what I expected".

> Is this vs2019 compiler bug and a known issue?
It's remarkable the number of wet behind the ears noobs who show up wondering whether it's a compiler bug (a compiler used by many 1000's of experienced professionals on a daily basis) is a possible alternative to their own code being wrong.