This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(278.4, 40%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDP%3C/text%3E%3C/svg%3E)
Hello
Our Coverity 2023.6.0 scan identify Uninitialized scalar field and Uninitialized pointer field issues using a CMap MFC class which is defined in /%ProgramFiles(x86)%/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.37.32822/atlmfc/include/afxtempl.h.
and
Do we use CMap in a wrong way?
There is no special construct available which would initialize those inner fields.
Can you give us an advise how shall we treat the Coverity finding or if this is a false positive finding?
Best Regards
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 86%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDL%3C/text%3E%3C/svg%3E)
Given that MFC is quite mature, and much of it predates more modern C++ usage, unless you find a problem with its use in CMap I think you should regard it as a false positive.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 13%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
While it is certainly best practice these days to initialise everything, leaving a variable uninitialised is, in itself, not a problem. Any problems are caused by a subsequent read from that variable without a write to set the value.
As a small example, consider the function:
int fun()
{
int a;
a = 10;
return a;
}
Even though a was uninitialised at definition, there was a write to the variable prior to the value being read. Modern compilers are likely to combine both statements to immediately initialise a too.
It is true for the MFC classes/structs too. Even if a member variable is not initialised in the constructor, as long as the member variable is written to at least once before it is read then the lack of initialisation isn't a problem.
So if there is still any uncertainty, even though @David Lowndes is correct with this assesment, then please check where these classes are being created and verify that all instances of these classes/structures have any uninitialised members written to before they are read.