Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Cppcheck output
- - By Anonymous [de] Date 2011-10-02 09:51
Hi. I just took the latest source code and let Cppcheck analyse it. Here is the output. While most of the stuf is minor style output, there are also some medium (performance, unused variables, ...) and major things like memory leaks and possible null pointer dereferences. Most of the stuff should be pretty straight forward to fix. Post splittet in two parts, because it was to long.


[src\C4Application.cpp:57]: (warning) Member variable 'C4Application::pGameTimer' is not initialized in the constructor.
[src\C4Application.cpp:780]: (warning) Member variable 'C4ApplicationGameTimer::fRecursing' is not initialized in the constructor.
[src\control\C4Control.cpp:455]: (error) Possible null pointer dereference: pSyncCheck - otherwise it is redundant to check if pSyncCheck is null at line 456
[src\control\C4GameParameters.cpp:370]: (warning) Member variable 'C4GameParameters::IsNetworkGame' is not initialized in the constructor.
[src\control\C4GameParameters.cpp:370]: (warning) Member variable 'C4GameParameters::AllowDebug' is not initialized in the constructor.
[src\control\C4PlayerControl.h:184]: (warning) Member variable 'C4PlayerControlAssignment::fComboIsSequence' is not initialized in the constructor.
[src\control\C4Control.h:140]: (warning) Member variable 'C4ControlScript::fUseVarsFromCallerContext' is not initialized in the constructor.
[src\control\C4Control.h:275]: (warning) Member variable 'C4ControlClientUpdate::eType' is not initialized in the constructor.
[src\control\C4Control.h:324]: (warning) Member variable 'C4ControlJoinPlayer::fByRes' is not initialized in the constructor.
[src\control\C4Control.h:354]: (warning) Member variable 'C4ControlEMMoveObject::eAction' is not initialized in the constructor.
[src\control\C4Control.h:381]: (warning) Member variable 'C4ControlEMDrawTool::eAction' is not initialized in the constructor.
[src\control\C4Control.h:381]: (warning) Member variable 'C4ControlEMDrawTool::fIFT' is not initialized in the constructor.
[src\control\C4Control.h:429]: (warning) Member variable 'C4ControlRemovePlr::fDisconnected' is not initialized in the constructor.
[src\control\C4PlayerControl.cpp:332]: (performance) Possible inefficient checking for 'KeyCombo' emptiness.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pResolvePacket' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fAnyChange' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pResolveInfo' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fCurrentConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fOriginalConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fAlternateConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pLowPrioOriginalConflictPacket' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pLowPrioAlternateConflictPacket' is not initialized in the constructor.
[src\control\C4Record.cpp:638]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:671]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:685]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:808]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:838]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:842]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:852]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:935]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:1233]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\editor\C4Console.cpp:266]: (style) Variable 'fOkay' is assigned a value that is never used
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::Editing' is not initialized in the constructor.
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::fGameOpen' is not initialized in the constructor.
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::PropertyDlgObject' is not initialized in the constructor.
[src\editor\C4ConsoleWin32.cpp:897]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\editor\C4EditCursor.cpp:621]: (style) Variable 'fObjectSelected' is assigned a value that is never used
[src\game\landscape\C4LandscapeRender.cpp:212]: (style) Variable 'pSurface' is assigned a value that is never used
[src\game\landscape\C4LandscapeRender.cpp:405]: (style) Variable 'iMat' is assigned a value that is never used
[src\game\landscape\C4MapCreatorS2.cpp:799]: (style) Exception should be caught by reference.
[src\game\landscape\C4MapCreatorS2.cpp:815]: (style) Exception should be caught by reference.
[src\game\object\C4ObjectPtr.h:32]: (warning) Member variable 'C4ObjectPtr::fDenumerated' is not initialized in the constructor.
[src\game\object\C4ObjectPtr.h:32]: (warning) Member variable 'C4ObjectPtr::data' is not initialized in the constructor.
[src\game\object\C4ObjectPtr.h:61]: (style) 'C4ObjectPtr::operator=' should return 'C4ObjectPtr &'
[src\game\object\C4Sector.h:41]: (warning) Member variable 'C4LSector::x' is not initialized in the constructor.
[src\game\object\C4Sector.h:41]: (warning) Member variable 'C4LSector::y' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::xL' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::yL' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::dpitch' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iDepth' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iMatchStart' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iMatchCount' is not initialized in the constructor.
[src\gui\C4Gui.h:1799]: (portability) Extra qualification 'ContextMenu::' unnecessary and considered an error by many compilers.
[src\gui\C4Gui.h:2753] -> [src\C4Prototypes.h:149]: (style) Typedef 'C4GUIScreen' hides typedef with same name
[src\gui\C4Gui.h:1844]: (style) The class 'ComboBox_FillCB' does not have a constructor.
[src\gui\C4ChatDlg.cpp:618]: (style) Variable 'pIRCChan' is assigned a value that is never used
[src\gui\C4GameOverDlg.cpp:171]: (style) Variable 'szNetResult' is assigned a value that is never used
[src\gui\C4KeyboardInput.cpp:597]: (style) Variable 'shift_idx' is assigned a value that is never used
Reply
Parent - By Anonymous [de] Date 2011-10-02 09:51
Second part:


[src\gui\C4LoaderScreen.cpp:153]: (information) The scope of the variable 'iLogBoxMargin' can be reduced
[src\gui\C4LoaderScreen.cpp:158]: (information) The scope of the variable 'fLogBoxFontZoom' can be reduced
[src\gui\C4PlayerInfoListBox.cpp:1365]: (style) Variable 'fAnyPlayers' is assigned a value that is never used
[src\gui\C4PlayerInfoListBox.cpp:1391]: (style) Variable 'fAnyPlayers' is assigned a value that is never used
[src\gui\C4StartupOptionsDlg.cpp:278]: (error) Possible null pointer dereference: assignment - otherwise it is redundant to check if assignment is null at line 276
[src\gui\C4StartupOptionsDlg.cpp:365]: (style) Variable 'pUseFont' is assigned a value that is never used
[src\gui\C4Viewport.cpp:682]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:686]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:702]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:704]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\lib\C4RTF.cpp:29]: (warning) Member variable 'C4RTFFile::fSkipDestIfUnknownKeyword' is not initialized in the constructor.
[src\lib\StdBuf.h:52]: (warning) Member variable 'StdBuf::pMData' is not initialized in the constructor.
[src\lib\StdBuf.h:52]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:57]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:89]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:340]: (warning) Member variable 'StdBuf::szString' is not assigned a value in 'StdBuf::operator='
[src\lib\StdCompiler.h:53]: (warning) Member variable 'StdCompiler::pWarnData' is not initialized in the constructor.
[src\lib\StdCompiler.h:692]: (warning) Member variable 'NameNode::Section' is not initialized in the constructor.
[src\lib\StdCompiler.h:692]: (warning) Member variable 'NameNode::Pos' is not initialized in the constructor.
[src\lib\C4Real.h:129]: (style) 'C4Fixed::operator=' should return 'C4Fixed &'
[src\lib\C4Stat.cpp:132]: (error) Mismatching allocation and deallocation: bHS
[src\lib\Standard.cpp:78]: (information) The scope of the variable 'xincr' can be reduced
[src\lib\Standard.cpp:78]: (information) The scope of the variable 'yincr' can be reduced
[src\lib\StdBuf.cpp:231]: (style) Variable 'pPos' is assigned a value that is never used
[src\lib\StdCompiler.cpp:850]: (error) Using sizeof with a numeric constant as function argument might not be what you intended.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pName' is not initialized in the constructor.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pPos' is not initialized in the constructor.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pReenter' is not initialized in the constructor.
[src\lib\StdMarkup.cpp:38]: (information) The scope of the variable 'iParLen' can be reduced
[src\lib\StdMesh.cpp:123]: (error) Possible null pointer dereference: svp - otherwise it is redundant to check if svp is null at line 122
[src\lib\StdMesh.cpp:126]: (error) Possible null pointer dereference: id - otherwise it is redundant to check if id is null at line 124
[src\lib\StdMesh.h:89]: (style) The class 'StdMeshMatrix' does not have a constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::Index' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::ID' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::Transformation' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::InverseTransformation' is not initialized in the constructor.
[src\lib\StdMesh.h:214]: (warning) Member variable 'StdMeshAnimation::Length' is not initialized in the constructor.
[src\lib\StdMesh.h:420]: (performance) Possible inefficient checking for 'IDs' emptiness.
[src\lib\StdMeshLoaderBinaryChunks.h:385]: (warning) Member variable 'ChunkMesh::bounds' is not initialized in the constructor.
[src\lib\StdMeshLoaderBinaryChunks.h:409]: (warning) Member variable 'ChunkSubmesh::hasSharedVertices' is not initialized in the constructor.
[src\lib\StdMeshLoaderBinaryChunks.h:286]: (warning) Member variable 'ChunkBase<ChunkID>::size' is not initialized in the constructor.
[src\lib\StdMeshMaterial.h:335]: (style) 'Iterator::operator=' should return 'Iterator &'
[src\lib\StdMeshLoaderXml.cpp:347]: (error) Possible null pointer dereference: bone - otherwise it is redundant to check if bone is null at line 342
[src\lib\texture\C4Surface.cpp:117]: (information) The scope of the variable 'max_scale' can be reduced
[src\netio\TstC4NetIO.cpp:46]: (style) The class 'MyCBClass' does not have a constructor.
[src\network\C4NetIO.cpp:2066]: (style) Variable 'fSuccess' is assigned a value that is never used
[src\network\C4NetIO.cpp:2609]: (warning) Redundant assignment of "iRIMCPacketCounter" to itself
[src\network\C4NetIO.cpp:276]: (warning) Member variable 'C4NetIOTCP::Pipe' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::Pipe' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::fMCLoopback' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::pCB' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1788]: (warning) Member variable 'C4NetIOUDP::pCB' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::fConnFailCallback' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iLastPacketAsked' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iLastMCPacketAsked' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iTimeout' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iRetries' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1788]: (warning) Member variable 'C4NetIOUDP::hDebugLog' is not initialized in the constructor.
[src\network\C4Network2Client.h:62]: (style) 'C4Network2Address::operator=' should return 'C4Network2Address &'
[src\network\C4Network2IRC.cpp:64]: (warning) Member variable 'C4Network2IRCUser::Next' is not initialized in the constructor.
[src\network\C4Network2IRC.cpp:72]: (warning) Member variable 'C4Network2IRCChannel::Next' is not initialized in the constructor.
[src\network\C4Network2IRC.cpp:188]: (warning) Member variable 'C4Network2IRCClient::pLogLastRead' is not initialized in the constructor.
[src\network\C4Network2Players.cpp:273]: (style) Variable 'pSaveInfo' is assigned a value that is never used
[src\network\C4Packet2.cpp:433]: (warning) Member variable 'C4PacketConnRe::fOK' is not initialized in the constructor.
[src\network\C4Packet2.cpp:433]: (warning) Member variable 'C4PacketConnRe::fWrongPassword' is not initialized in the constructor.
[src\platform\C4MusicSystem.cpp:235]: (style) Variable 'szExt' is assigned a value that is never used
[src\platform\C4SoundLoaders.h:39]: (warning) Member variable 'SoundInfo::sample_length' is not initialized in the constructor.
[src\platform\C4SoundLoaders.cpp:139]: (style) Unused variable: spaceToEOF
[src\platform\C4Video.cpp:263]: (style) Variable 'iWidth' is assigned a value that is never used
[src\platform\C4ViewportWindow.cpp:255]: (style) Variable 'fMinimized' is assigned a value that is never used
[src\platform\C4ViewportWindow.cpp:256]: (style) Variable 'fMaximized' is assigned a value that is never used
[src\platform\StdWindow.h:253] -> [src\platform\StdApp.h:36]: (style) Struct 'Display' hides typedef with same name
[src\platform\StdD3D.cpp:834]: (information) The scope of the variable 'sp' can be reduced
[src\platform\StdD3D.cpp:890]: (information) The scope of the variable 'sp' can be reduced
[src\platform\StdDDraw2.cpp:611]: (style) Variable 'scaleX2' is assigned a value that is never used
[src\platform\StdDDraw2.cpp:612]: (style) Variable 'scaleY2' is assigned a value that is never used
[src\platform\StdFile.cpp:813]: (error) Resource leak: d
[src\platform\StdFont.cpp:504]: (information) The scope of the variable 'iCharWdt' can be reduced
[src\platform\StdFont.cpp:660]: (information) The scope of the variable 'iCharWdt' can be reduced
[src\platform\StdGLCtx.cpp:435]: (style) Variable 'i' is assigned a value that is never used
[src\platform\StdRegistry.cpp:77]: (style) Variable 'qerr' is assigned a value that is never used
[src\platform\StdRegistry.cpp:133]: (style) Variable 'qerr' is assigned a value that is never used
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::KeyMask' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::dpy' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xf86vmode_major_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xf86vmode_minor_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xrandr_major_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xrandr_minor_version' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::fRunThreadRun' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::fWait' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::iThread' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:459]: (warning) Member variable 'StdThread::iThread' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_oldmode' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_rot' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_event' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::wdt' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::hgt' is not initialized in the constructor.
[src\platform\StdXPrivate.h:59]: (warning) Member variable 'CGLibProc::timeout' is not initialized in the constructor.
[src\platform\StdXPrivate.h:59]: (warning) Member variable 'CGLibProc::max_priority' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:329]: (information) The scope of the variable 'varIndex' can be reduced
[src\script\C4AulDebug.cpp:36]: (warning) Member variable 'C4AulDebug::eState' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:36]: (warning) Member variable 'C4AulDebug::iStepCallDepth' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:44]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulDebug.cpp:319]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulDebug.cpp:506]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::fProfiling' is not initialized in the constructor.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::pProfiledScript' is not initialized in the constructor.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::Contexts' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::Idtf' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::cStr' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::Type' is not initialized in the constructor.
[src\zlib\gzio.c:26]: (style) struct or union member 'internal_state::dummy' is never used
[src\zlib\gzio.c:158]: (error) Memory leak: s.path
[src\zlib\gzio.c:526]: (error) Uninitialized variable: c
Reply
Parent - - By Anonymous [de] Date 2011-10-02 09:59
Would it be OK, If I fix some of these and submit a patch?
Reply
Parent - - By Maikel Date 2011-10-02 10:06
Yes, off course. You can attach them here.
Parent - - By Anonymous [de] Date 2011-10-02 10:59
OK, I fixed the easy ones (the ones that don't need compiling and much thinking, don't have time to set up build environment for OC now). I also two or three //FIXMEs on code that looked suspicious.

I uploaded the patch file to a free file hoster:
cppcheck.patch
Reply
Parent - - By PeterW [gb] Date 2011-10-02 13:25
Huh, those seem a bit dubious.

> +    //FIXME: double negation?


What is there to fix about it? That's an explicit bool conversion (e.g. from windows BOOLs). I use that construct all the time.

> -  catch (C4MCParserErr err)
> +  catch (C4MCParserErr& err)


I don't get the difference - wouldn't it have to copy stuff behind the scenes anyway? And a *non-constant* reference to what is most likely a RHS object? That type of thing has bitten us before...

>-    for(x = 0; x < To.Wdt; x++) {
>+    for(x = 0; x < To.Wdt; ++x) {


What?

>-      int iMat = pSource->_GetMat(To.x+x, To.y+y);
>+            pSource->_GetMat(To.x+x, To.y+y);


What about "I foresee that this variable will be used in future revisions"? :)

> -      szNetResult = LoadResStr("IDS_TEXT_LEAGUEWAITINGFOREVALUATIO");
> +      LoadResStr("IDS_TEXT_LEAGUEWAITINGFOREVALUATIO");


That seems a bit inconsequential (LoadResStr doesn't have side effects, that's for sure). And Sven should have a look at whether not doing anything with the network status there was actually his intention.

>-  const char *szExt = GetExtension(szFile);
>+  GetExtension(szFile);
>   // get type
>   switch (GetMusicFileTypeByExtension(GetExtension(szFile)))


Maybe just use "szExt" in the line below?

Judging from your list, those "not initialized" lines seem like the most likely candidates for actual bugs.
Parent - - By Anonymous [de] Date 2011-10-02 15:45
Sorry that I provided my help, I will refrain from doing so in the future.

You should always use prefix in/decrement. x++ is x = x + 1 which means that a temporary copy of x needs to be created which is then raised by one and copy over to the original adress. While ++x is just "Go to address of x and raise by one". While this doesn't really affect ints and similar, it will however get very cpu consuming if in/decrementing non-primitive types. So you should always use prefix for a simple reason: to not get used to postfix, even on primitives (even Stroustrup, the C++ inventor, will tell you this, He even says that the language should from a programmers POV really be called ++C instead - but it doesn't because C++ simply sounds better).

I removed some unused variables (why waste memory and cpu time for them?), but not the function calls that assigned them a value, because maybe these calls were needed (as I said, I did not set up a build environment and tested things and checking what these functions do, that's why I only did the easy hacks now).

You should never create variables because "you maybe need them in 100 years". You will forget about (most of) them (->wasting memory and cpu time to create them at runtime).

BOOL is just "typedef int BOOL", the proper way of converting an int to bool is this:
bool b = (BOOLvar != 0);

Bye.
Reply
Parent - - By Günther [de] Date 2011-10-02 16:47
Well, we don't really need help with fixing warnings, especially those from tools with a lot of false positives. But we certainly do need help implementing all those interesting features we want to play with in the future!

As a matter of public service, I'm now going to point out some misunderstandings about compilers and coding style contained in the post I'm answering to. Don't take this personally.

> While this doesn't really affect ints and similar


In fact it doesn't affect them at all. The compilers are smart enough to treat both variants the same way, and the chance of the integers being replaced with more complex objects with custom operators is small, and even then inlining probably takes care it it. Changing them around won't help the original person who wrote them the other way around, so it's better to avoid the noise in the version history.

>why waste memory and cpu time for them?


Indeed, and the compiler doesn't. Those variables are left there as a sort of todo list for someone to investigate whether the function call is still needed.

The proper way of converting an int to a bool is not to use an int in the first place. If you can't do that, !! is as good as != 0, and both are inferior to eliminating the bool and using if(foo) or similar.
Reply
Parent - - By Anonymous [de] Date 2011-10-02 18:21
Why should I contibute feature code if nobody of the team seems to care about code style? I have no wish to contribute to a project that hasn't a clean rule set about code style (actually, not having one yet isn't the problem, but don't even want to have one is).

How do you intend to get new code contributors if you cut them off from the beginning? You can't expect everyone to do big feature contributions from the start. You should allow small contributions and clean up tasks if this helps people to get into the project.

> Indeed, and the compiler doesn't.


What's "the compiler"? There exists a lot of different compilers with a lot of different optimization techniques that can be switched on and off.

Initially I thought OpenClonk is a very good open source project (you have a really good and clean website with all needed informations). But seeing that you don't even have a code style plan and cut off easy beginner tasks and don't like the use of static analysis tools to find possible flaws it seems I have to revise my opinion about OpenClonk: While your code base and licence is open, the actual development process seems not to be "open" (as in "we don't want anything from you if you don't completly take over our opinions about the development process!").
Reply
Parent - - By Ringwaul [ca] Date 2011-10-02 19:20
Oh, seriously, stop trying to be so dramatic. If this were a forum where someone left in a hissy fit because everyone didn't unanimously agree with them, this would be a very empty project.

Development requires discussion, and if you think you're being personally insulted because your contributions aren't immediately included you need to grow up.
Reply
Parent - - By Anonymous [de] Date 2011-10-03 11:14
What about a welcoming word? A thanks? What about "Thanks for your effort, but I see some problems here: This and that, but the rest looks fine. Thanks again. :) " ?

Bashing a well-meant effort into the trashcan without some thanks or constuctive arguments and no word about the good parts is no "discussion".

Sorry to say that, but the OC community looks unfriendly to me. Of course, you are doing great work on the game, no doubt, but I don't like the whole "atmosphere". I know other open source projects to which I contributed similar work, but OpenClonk was the first that reacted instantly negative to it.
Reply
Parent - By Ringwaul [ca] Date 2011-10-03 11:41

>"What about a welcoming word? A thanks? What about "Thanks for your effort, but I see some problems here: This and that, but the rest looks fine. Thanks again. :) " ?


We didn't react negatively to you, you submitted something and under the presumption that you knew what you were talking about the engine programmers started talking straight towards the business of the matter.

Why you perceived critique as insulting is unknown to me. Because the programmers skipped pleasantries and went straight to discussion? The atmosphere of development is hardly elitist as you seem to perceive; we've had plenty of people who just randomly came in and fixed or improved something (check the about menu in the game for a list!). But you can't honestly expect just because it's open-source everything you contribute will automatically be included without others reviewing your work. I also have had people contribute do work in the content/art area that I have reviewed before adding.

If you want to contribute to OC, no one is stopping you; in fact, we need more developers as it is! But when you contribute something, expect to receive criticism. Even in something as casual as open-source hobby development there is a degree of professionalism that is expected.
Reply
Parent - - By PeterW [gb] Date 2011-10-03 13:04 Edited 2011-10-03 13:35
To cite myself from yesterday:

Okt 02 20:45:37 <PeterW>  And left me wondering whether I'd have avoided that with a simple "First of all, thanks for looking at OpenClonk! Most of the issues you raise are valid, but I have a few doubts about how to fix them..."
Okt 02 20:45:52 <PeterW>  It just feels so silly :/
Okt 02 21:01:31 <maikel`>  being nice feels silly?
Okt 02 21:01:35 <maikel`>  I agree
Okt 02 21:01:39 *  maikel` ist jetzt bekannt als Maikel
Okt 02 21:02:38 <PeterW>  I don't know. I always feel like cutting right to the chase is the right thing to do with someone you think knows what he's doing.
Okt 02 21:03:15 <PeterW>  If I didn't believe in it, I wouldn't respond.


Oh well. Günther has btw started doing some patches based on your observations, if I understood him correctly.

Edit: That's the thing about internet communication. My first reaction was "hey, sounds like a nice idea". Then I looked at the patches and couldn't help but feel disappointed at how much work this still needed to get useful. That's what my post reflects.

Before that gets lost: I still think that we should hunt down those missing initializations. Some warnings in the network code don't sound right. If our Mr. or Ms. Anonymous doesn't want to work with us anymore, we should probably look into getting this tool of his installed ourselves for that reason alone.
Parent - By Günther [de] Date 2011-10-03 17:06 Edited 2011-10-03 17:11
No, I just had some patches lying around based on gccs initialized-but-unused warnings, which I didn't push out before because none were critical and I didn't want to delay or risk to delay the release. Cleaning up warnings isn't as trivial as it sounds at first - the last time someone not in the team did that on a large scale he managed to introduce a new bug and changed an if(foo=bar) to an if((foo=bar)) instead of the intended if(foo==bar).
Reply
Parent - By Zapper [de] Date 2011-10-02 19:20
Sorry, if everyone has seemed so hostile :x
http://wiki.openclonk.org/w/Style_Guidelines !
Parent - By Günther [de] Date 2011-10-02 20:00

> Why should I contibute feature code if nobody of the team seems to care about code style?


Part of our coding style is "do not fix warnings from automated analyzers without understanding the root cause". Your patch simply hid some problems with the code, making them harder to find. If you don't understand why that's bad, you probably shouldn't try to contribute.

> How do you intend to get new code contributors if you cut them off from the beginning?


By encouraging them to write patches that won't get "cut off". If they misunderstand patch review comments as personal rejections, we are better off without them. We try to maintain high quality standards, and reviewing each others patches is necessary for that. (Though we do some of that as commit-then-review, but for anonymous contributors that's impossible.)

> What's "the compiler"? There exists a lot of different compilers with a lot of different optimization techniques that can be switched on and off.


If you're using a non-optimizing compiler, you shouldn't change the code to make it faster. By the way, gcc -O0 generates the same code for "for (int i = 0; i < 42; i++) bar();" and "for (int i = 0; i < 42; ++i) bar();", and "int k; for (int i = 0; i < 42; ++i) k = bar();" only adds a single MOV, which is lost in the noise. Big projects like Clonk always have far, far bigger optimization opportunities, and getting sidetracked by believing microoptimizations were significant only results in slowdown. I know it's hard, I often have to consciously keep myself from getting thus distracted.
Reply
Parent - By PeterW [gb] Date 2011-10-02 21:03 Edited 2011-10-02 21:06

> as in "we don't want anything from you if you don't completly take over our opinions about the development process!


Uhm, no. Our policy is actually the other way round: The idea is that we don't subject coders to silly style rules like "never use post-increment". Now you have told me to stop doings things that I have been doing on purpose and with some thought behind it.

Style discussions are a mine field - with a lot of developers involved you are sure to get disagreement. Doing a swooping pass over the engine and wildly changing everything that you would have done slightly different... Well, that's just a recipe for stepping on people's toes. I certainly wouldn't recommend it if you don't have strong real-world arguments that go a bit above citing Stroustroup or the C++ FAQ.
Parent - By PeterW [gb] Date 2011-10-02 20:32 Edited 2011-10-02 20:49

> Sorry that I provided my help, I will refrain from doing so in the future.


Well, to make that clear - I am glad to see people getting interested in this. I just wanted to note that while the issues you raise are valid, the fixes are in most cases not so obvious.

> You should always use prefix in/decrement.


I am aware of the issue for non-primitive types. But why change it around for integers, where constructing a reference is equally complicated as saving the old value - and both should really be optimised away by the compiler?

> because maybe these calls were needed


Well yes, I understand that. I am just telling you that all the instances you noticed there *have* no side-effects and therefore removing them completely would be the better solution.

> wasting memory and cpu time to create them at runtime


Uhm, no? The compiler is at least as intelligent as your tool and will not allocate any runtime data. At least for primitive types. The overhead we're talking about is purely the source complexity. That's still a valid point, but a bit less so.

> the proper way of converting an int to bool is this:


Is it? For me that's breaking the abstraction by showing that the BOOL is an int. What if that changes in future? All I really know is that whatever BOOL is, it supports "!" which gives me a bool. I don't want to assume more.

> Bye.


Note I am doing computer language research semi-professionally. Please don't interpret my eagerness to discuss fine points of style as dismissal :)
Parent - By Newton [de] Date 2011-10-04 18:53

> OK, I fixed the easy ones


What about the rest of Anonymous' contribution though? You looked through it, is there something we can make use of?

At the very least, if he detected memory leaks and possible null pointer exceptions with this tool, we should definitely go after them.
Parent - By MimmoO Date 2011-10-03 17:08

>because it was to long.


http://pastebin.com/
Up Topic Development / Developer's Corner / Cppcheck output

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill