I added some initializations in CVS to silence those warnings, but they are 
rather meaningless, in the sense that it is just a case of VC's code analyzer 
not being able to prove that if a cosmic ray were to strike the CPU in just the 
right manner and a bit was to flip, the value might be used unitialized. 
Technically those cases can never be reached, although the WSASendTo case was 
just using 0 where I needed a NULL (too much C++ on the brain). Oh well, 
sometimes it is easier to just do what the compiler says to make it stop 
nagging. :)

On 12/29/2011 05:57 PM, Ruud van Gaal wrote:
Having just read a blog from John Carmack on static code analysis tools, I 
decided to start analyzing my own code. (see 
http://altdevblogaday.com/2011/12/24/static-code-analysis/ )
Part of it is ENet, quite the latest version. These are the 3 results:

1>d:\source\trunk\dev\src\libs\enet\peer.cpp(743) : warning C6001: Using 
uninitialized memory 'reliableSequenceNumber': Lines: 715, 717, 718, 719, 720, 
721, 723, 726, 739, 741, 742, 743
1>d:\source\trunk\dev\src\libs\enet\protocol.cpp(222) : warning C6001: Using 
uninitialized memory 'outgoingCommand': Lines: 173, 174, 175, 176, 178, 179, 189, 
210, 222
1>d:\source\trunk\dev\src\libs\enet\win32.cpp(244) : warning C6387: 'argument 
6' might be '0': this does not adhere to the specification for the function 
'WSASendTo': Lines: 224, 225, 227, 244

Not sure how the first 2 might be problems; perhaps someone else has a better 
clue?

Cheers,
Ruud van Gaal


_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss

_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss

Reply via email to