Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Possible problems in keybinder?

(1/2) > >>

Der Meister:
While compiling the recent revision I noticed a warning:

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

--- End quote ---
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);
}

--- End code ---
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();
}

--- End code ---
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:

--- Quote from: Der Meister on March 25, 2006, 10:51:40 pm ---While compiling the recent revision I noticed a warning:
keybinder.cpp:2234: warning: 'n' might be used uninitialized in this function

--- End quote ---

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:

--- Quote from: Der Meister on March 26, 2006, 11:20:27 am ---Maybe I'll compile Code::Blocks with icc again - this compiler usually finds more this problems and prints warnings etc. that gcc does.

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page