Possible problems in keybinder?

[Der Meister]

While compiling the recent revision I noticed a warning:

keybinder.cpp: In member function `void wxKeyConfigPanel::OnAssignKey(wxCommandE                             
vent&)':
keybinder.cpp:2234: warning: 'n' might be used uninitialized in this function

The corresponding lines of the sourcode are:

Code

	if (m_pCurrCmd) {
		wxKeyBind tmp(m_pKeyField->GetValue());
		int n;

#ifdef __WXDEBUG__
		bool bind = m_pCurrCmd->IsBindTo(tmp, &n);
		wxASSERT_MSG(bind, wxT("the m_pCurrCmd variable should be NULL then..."));
#endif		// to avoid warnings in release mode

		m_pCurrCmd->RemoveShortcut(n);
	}

I don't know what this code should do - I simply don't understand it. But if __WXDEBUG__ is not defined the call to wxCmd::RemoveShortcut uses an uninitialized value. I don't think that this is should be done.

And in wxCmd::RemoveShortcut I suspect the next problem:

Code

	void RemoveShortcut(int n) {
		for (int i=n; i < m_nShortcuts; i++)	// shift array left
			m_keyShortcut[i] = m_keyShortcut[i+1];
		m_nShortcuts--;
		Update();
	}

This looks like a buffer overflow because there should be m_nShortcuts elements in the array - but in this part of the code the element with *index* m_nShortcuts is accessed...

[killerbot]

I don't know the code either, maybe just the asset should be between the ifdefs, as it is now it is certainly wrong.

[Pecan]

While compiling the recent revision I noticed a warning:
keybinder.cpp:2234: warning: 'n' might be used uninitialized in this function

thanks, I'll fix this stuff.

How did you get the warning msg. I've got "Enable All Compiler Warnings" turn on. and I can't get the msg.

gcc version 3.4.4 (mingw special)

thanks
pecan

[Der Meister]

I'm using gcc 3.4.5 on Linux and added -Wall as command-line parameter. Then I got this warning. Maybe gcc 3.4.4 did not see this because of the preprocessor macros? Or maybe I just had not defined __WXDEBUG__?

Maybe I'll compile Code::Blocks with icc again - this compiler usually finds more this problems and prints warnings etc. that gcc does.

[yop]

Maybe I'll compile Code::Blocks with icc again - this compiler usually finds more this problems and prints warnings etc. that gcc does.

It prints tons of remarks, even for the simplest things that we all do. This compiler, though I just love it, can be *really* strict. But it would be a good thing to pass C::B through this one before the next release and hand out the results to the devs. I was even thinking to run it through vtune (if someone could get me some time off my job, I promise I will :lol:), but it would take some time to setup the testing environment and "decode" the results.

[Der Meister]

Well, I fear that no one really wants to do this. I just compiled Code::Blocks (with contrib-plugins) using icc with the linux make-system and I redirected all warnings and remarks to a file (thus the file contains all warnings and remarks but not the command-line). This file is about 4.3MB big 
Anyway, most of this remarks and warnings can surely be ignored without any risk and there are a lot of warnings about command-line parameters that icc doesn't understand (like -ffast-math oder -Winvalid-pch). That makes the file bigger as it has to be. But finding important warnings/remarks (if there are any!) in this huge file will be terrible. I'm not sure if anyone wants to do this... 

[yop]

This file is about 4.3MB big 

Doesn't even worth to try then. You can play a lot with the level of detail you want in the icc output, but I don't know if it's worth the efford.

[MortenMacFly]

[...] there are a lot of warnings about command-line parameters that icc doesn't understand (like -ffast-math oder -Winvalid-pch).

You could "grep off" these lines and similar (not important things) and see what's remaining, maybe.
With regards, Morten.