Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z
The 11 February 2012 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20120211_rev7789_win32.7z
- Linux :
none
Resolved Fixed:
- added batch build files for build and re-build of core and plugins (Windows only atm)
- BrowseTracker - JumpTracker:record deactivated position rather than activated position
- adjust SDCC's options
- do not connect events to dummy editor (used to backup foldstate), avoid moving breakpoints after the end of the file and probably other issues
- linux: fix build-errors with automake-system, if "make dist" was not used from C::B's root-folder
- Fixed: bug discussed here: http://forums.next.codeblocks.org/index.php/topic,15847.0.html
- applied patch #3226 and extended part list with devices supported by gcc-4.5.3
- attempt to make KEY_DOWN work in management pane
- CC: made some of the options persist again
- CC: added support for __attribute__ statements in structs (classes, typedefs)
- CC: better handle const and volatile in front of namespaces (classes)
- CC: major re-factoring to separate hidden classes and global hidden methods (using separate files and/or namespaces)
- Fixed: Compilation of CodeSnippets with wxWidgets-2.8.12
- added new cbEditor API to jump to specific line/token (preparation to remove global function from CC)
- CC: renamed some token variabes to make clear what there are for
- CC: overworked parsertest massively to parse files serialised but creating ONE TokensTree (not many temporary)
- CC: major refactoring to allow the use of the CCDEebugInfo dialog in ParserTest project (via menu -> find -> token)
- CC: optmised ParserTest application to make use of a file queue (enables to parse files serialised and added in between)
- CC: ParserTest allows to scan priority files first (if needed, handle with care -> can take long!)
- made About dialog work properly (i.e. not crash) under wx 2.9.x
- cbProject: fixed possible crash candidate in CloseAllFiles (most likely on shutdown)
- Fixed: Compilation warnings with -Woverloaded-virtual switch
- CC: made ParserTest "reload" work again
- CC: optimised and clarified interface to "SkipToOneOfChars" in parser thread
- help-plugin: fix annoying occasionally happening crash on shutdown ("double free or corruption" or "corrupted double-linked list"), due to linking against static-libs, that are already linked in through libcodeblocks.so (linux only); style changes
- CC again: major refactoring concerning lockers
- CC: extracted more classes so they can be used/tested in ParserTest (automake updated)
- CC: fixed entering a critical section too often in class browser
- removed wx 2.4.x compatibility artefacts (C::B does not compile on wx 2.4.x anyways anymore...)
- wxWidgets 2.9 related changes: add unix-project-file and update-script; small build-fixes; (hopefully) get rid of the annoying crash on close, due to event-handlers
- cclogger: updated CC macros to enable simply assert mode
- Prevent crash on exit due to referencing unallocated memory from wxArray::Remove (courtesy of Pecan)
- CC: fix a build error when CC_ENABLE_LOCKER_ASSERT is defined
- CC: fixed a hang on CC, reported here: http://forums.next.codeblocks.org/index.php/topic,15885.msg107044.html#msg107044
- CC: separated CCTreeControl into own file
- CC: use Mutex instead of critical section for Parser, as it can be traced to a deadlock! (wxCriticalSection just freezes)
- CC: separated locker macros, so that individual mutexes can be traced
- Show an InfoWindow, when the end of the document is reached, while using the Search->Find function;
- add missing cctrectrl.{cpp,h} to linux projectfile, add cctrectrl.h to windows projectfile
- speed up closing large project; (hopefully) finally fix a crash on close, that occurs from time to time, see: http://forums.next.codeblocks.org/index.php/topic,15901.msg107140.html#msg107140 and http://forums.next.codeblocks.org/index.php/topic,15882.msg107033.html#msg107033
- CC: pause / resume thread for safety if class browser is updated, so the thread cannot be interrupted anymore
- CC: send event from class browser thread to parent (class browser) if something relevant changes
- Valgrind plugin : replace macros
- CC-plugin: avoid possible infinite wait, if cc-plugin should be disabled, by adding a termination request; avoid possible memory-violation in UpdateLayout, if classbrowser is floating
- envvars plugin: fixed bug described here: http://forums.next.codeblocks.org/index.php/topic,15926.msg107296.html#msg107296
- CC: updated parsertest to be way faster and show progress of tokens added
Regressions/Confirmed/Annoying/Common bugs:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
I changed the presprectives twice and got this!!
(http://i.minus.com/iuUgY0eKgAKDp.png)
I restarted Code Blocks and it worked fine.. Still thought of reporting
Can you reproduce this problem after you've restarted C::B?
Quote from: oBFusCATed on February 14, 2012, 07:48:45 PM
Can you reproduce this problem after you've restarted C::B?
Thats the wonder. It never happened again as of yet!!
I also had such behavior using the previous nightly (7678).
I guess this was related with my intensive use of the Windows hibernation. I did not close CB for several days and only switched Windows to the hibernation mode and then resumed Windows every day. Once I stopped to use the Windows hibernation with no closing CB completely the problem was not encountered anymore.
Maybe this may help to find a direction.
Quote from: janissl on February 15, 2012, 06:25:16 PM
I also had such behavior using the previous nightly (7678).
I guess this was related with my intensive use of the Windows hibernation. I did not close CB for several days and only switched Windows to the hibernation mode and then resumed Windows every day. Once I stopped to use the Windows hibernation with no closing CB completely the problem was not encountered anymore.
Maybe this may help to find a direction.
Nope its not that as i never hibernate my laptop!
Quote from: neo1691 on February 15, 2012, 06:26:19 PM
Nope its not that as i never hibernate my laptop!
Then I was wrong. Perhaps, I also switched between perspectives and then got this error but anyway I can not reproduce it anymore.
great,thanks
1. Browser tree: I still cannot open files in minibrowser by pressing ENTER.
2. Editor settings: Why there is "selection" color option only for "C/C++"? (while it should probably be syntax-independent?) UPD: sorry, not only "C/C++" but still kinda irrational.
3. Editor settings: No "default" or "unknown" type. I just don't understand how to configure base colors for simple text files. (probably these settings, if implemented, should be inherited by all others?)
svn build rev 7789 (2012/02/11 03:42:39) gcc 4.5.2 Windows/unicode - 32 bit
Win2003 5.2 R2 build 3790
As always, thank you for your great work.
I really hope to join one day.
Quote from: xawari on February 20, 2012, 10:51:08 PM
2. Editor settings: Why there is "selection" color option only for "C/C++"? (while it should probably be syntax-independent?) UPD: sorry, not only "C/C++" but still kinda irrational.
Look inside the
lexer_*.xml files; within
lexer_cpp.xml there is:
[...]
57. <Style name="Operator"
57. index="10"
59. fg="255,0,0"/>
60. <Style name="Selection"
61. index="-99"
62. bg="192,192,192"/>
63. <Style name="Active line"
64. index="-98"
65. bg="255,255,160"/>
[...]
Selection color is not accessible in most other languages simply because no one has added that tag.
I had to change a project from folder and when opening the project, it obviously couldn't find those files.
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\C2dShock.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\C2dShock.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CAddTransparencyCB.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CBlurShader.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CBlurShader.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CDepthMapCallback.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CDepthMapCallback.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CFXAA.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CMotionBlur.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CMotionBlur.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CNightVision.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CPostProcessingHandler.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuad.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadCB.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadCB.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadSceneNode.cpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadSceneNode.hpp" />
<Unit filename="..\..\..\..\projets\bc0.2\libs\mirrpp\CScreenQuadShader.hpp" />
but I couldn't remove them from the interface, I've been compelled to edit manually the project file.
teto: Can you provide the exact steps to reproduce this problem?
I've tried to reproduce it without success. I may have been misled by the fact we can select several files in the projet but when we choose "remove from project" (right click) it just removes the file clicked. I will be more careful next time I spot sthg weird
Out of curiosity, when will you guys going to release the next release? People come in IRC channel and ask about it; frankly it's been almost two years now.
Also, I have noticed this release-delay in the past, that lasted 2 years since the official switch of version numbering scheme (8.02) to reach the next stable version (10.05).
What is the most stable revision that could be assembled in an installer and ship it to download session so people can see some activity from the project?
Looking forward to hear your reply.
SVN HEAD is as stable as it could get :)
Quote from: oBFusCATed on February 27, 2012, 11:05:59 PM
SVN HEAD is as stable as it could get :)
I trust it is very stable. I am using the current head for a new release of Codeblocks EDU-Portable (in a couple of weeks).
Quote from: Alpha on February 20, 2012, 11:55:22 PM
Selection color is not accessible in most other languages simply because no one has added that tag.
There's no such lexer as default/common, it's really a bad idea to add same setting to every language. There may be someone who wants to highlight different text in different colors, of course, but in general there should be a common base. IMHO.
When using the "Insert -> All method without implementation" to insert the implementation of TestFunction() for this header file:
TestClass.h
#ifndef TESTCLASS_H
#define TESTCLASS_H
class TestClass
{
public:
TestClass();
virtual ~TestClass();
int* TestFunction();
};
#endif // TESTCLASS_H
I got following code:
TestClass.cpp
#include "TestClass.h"
TestClass::TestClass(){}
TestClass::~TestClass(){}
int TestClass::TestFunction()
{
}
The return type of TestFunction missed the "*".
I have tried reparsing the project, but the problem is still there.
many thanks for the feedback, this is indeed a serious error.
Could you please also register it at our berlios project page as a bug, otherwise it will get lost in the forum ;-)
I can confirm the error submitted by zetab, I can also say that it happens for C functions and not only for C++ classes (C functions that return char* are shown as returning char), and I have found another serious flaw with return types:
As one types a simple C program like this:
#include <stdio.h>
#include <stdlib.h>
int main()
{
printf(
}
Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
Quote from: Agetian on March 09, 2012, 12:52:17 PM
Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
This is known but not an easy thing to do. I've done some work on it which improves this, but not fully completed yet.
Quote from: MortenMacFly on March 09, 2012, 03:41:46 PM
Quote from: Agetian on March 09, 2012, 12:52:17 PM
Upon typing the opening bracket of the standard function 'printf', which fires the printf declaration hint, the hint will show the function as "__MINGW_NOTHROW printf(const char*, ...)" thus omitting the return type (int) and the other declarations (_CRTIMP, __cdecl). Tested with the latest nightly (from this thread) and MinGW GCC 4.6.1.
This is known but not an easy thing to do. I've done some work on it which improves this, but not fully completed yet.
Also, I'm not sure if it's supposed to work (I think it used to work a couple builds ago, but my memory is a bit blurry), but the declaration hint is not shown for function-like macros, e.g. in this stupid little test macro:
#define TEST_MACRO(x) ((x) * (x))
int main()
{
TEST_MACRO(
}
Quote from: zetab on March 09, 2012, 10:24:14 AM
When using the "Insert -> All method without implementation" to insert the implementation of TestFunction() for this header file:
TestClass.h
#ifndef TESTCLASS_H
#define TESTCLASS_H
class TestClass
{
public:
TestClass();
virtual ~TestClass();
int* TestFunction();
};
#endif // TESTCLASS_H
I got following code:
TestClass.cpp
#include "TestClass.h"
TestClass::TestClass(){}
TestClass::~TestClass(){}
int TestClass::TestFunction()
{
}
The return type of TestFunction missed the "*".
I have tried reparsing the project, but the problem is still there.
I have find the reason, see the comments in Insert all class methods without implementation malfunction (https://developer.berlios.de/bugs/?func=detailbug&bug_id=18526&group_id=5358)
I think it can be fixed quickly, but that fix should be reviewed. :)
Quote from: Agetian on March 11, 2012, 09:16:41 AM
Also, I'm not sure if it's supposed to work (I think it used to work a couple builds ago, but my memory is a bit blurry), but the declaration hint is not shown for function-like macros, e.g. in this stupid little test macro:
#define TEST_MACRO(x) ((x) * (x))
int main()
{
TEST_MACRO(
}
It works here, WinXP, c::b trunk.
See the screen shot below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-03-12141532.png)
Quote from: ollydbg on March 12, 2012, 07:16:46 AM
It works here, WinXP, c::b trunk.
See the screen shot below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-03-12141532.png)
Hmm, I'm not sure if it's the newer build you might be testing with (so it's already fixed?) or something OS-specific/compiler toolchain-specific; at any rate, I'm testing it with SVN 7789 (from this thread) on Windows Vista 32bit with MinGW GCC 4.6.1 (tdm-gcc). It doesn't work for me under these circumstances. :\
Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing? I have tried with both svn-7789 and the latest svn-7905 and it crashes like mad.
Below you may find the generated crash report. It would help a lot your valuable feedback.
Cheers.
Quote from: stefanos_ on March 20, 2012, 10:23:34 PM
Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing?
Tested under latest trunk and winXP, no crash.
Quote from: stefanos_ on March 20, 2012, 10:23:34 PM
Can someone try to close multiple .xrc or .wxs and tell me if his / her system is crashing? I have tried with both svn-7789 and the latest svn-7905 and it crashes like mad.
Below you may find the generated crash report. It would help a lot your valuable feedback.
Cheers.
did you really clean your sozrce folder before building, especially remove the +.gch's in c::B's include ? They have moved to another place, but if old ones exist, they will probably be used by the compiler, what can lead to weird crashes.
A fresh svn-checkout is usually the easiest way to avoid such issues.
jens, I have forgot to mention that it's under Debian wheezy. I have created a script and it runs like this:
make clean && \
make distclean && \
./bootstrap && \
./configure --with-contrib-plugins=all && \
make && sudo make install
Up to now it was working just fine, cleaning literally everything that I could see. This issue appeared in svn-7789 and afterwards. Shall I try to uninstall it and run a clean install?
Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
So it is advised to do one of two things:
1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing, so you have an easy uninstall procedure (just delete the directory).
2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm based distros (some changes are needed here and there, but they are trivial).
BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here: http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch, so we can integrate your changes? (this link is from the irc.freenode.net channel posted by the user _stefanos_ (I guess this is you)).
p.s. also it could be a good idea to use a separate build directory, our build system supports it pretty well (I've not tried it, but this is what people say:)).
Quote from: oBFusCATed on March 21, 2012, 08:25:42 AM
Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
So it is advised to do one of two things:
1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing,
so you have an easy uninstall procedure (just delete the directory).
2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm
based distros (some changes are needed here and there, but they are trivial).
BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here:
http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch,
so we can integrate your changes? (this link is from the irc.freenode.net channel posted by
the user _stefanos_ (I guess this is you)).
p.s. also it could be a good idea to use a separate build directory, our build system supports it
pretty well (I've not tried it, but this is what people say:)).
Yeah that's my website. Well, I had an issue from the start with many awkward messages about missing macros from
those two files and searched about it on the web. I have found bits and pieces as plausible fixes and assembled
them as one whole solution and managed to make it work; frankly I thought it was a minor bug that had to do
with my system, not with Code::Blocks. I thought it would, could, (should?) have got fixed by now; I didn't know that
still causes building problems so I could report my solution as an official patch for Code::Blocks.
As far as concern the build directory, I have tried it once and I found it irritating with all this switch between
build version and installed version, that is the one I have compiled myself, and the one that comes on Debian
by default. It was based on this irritation that I decided to compile everything myself, which is more or less
an old habit I would say; it helps me stay focus on one thing.
Right now I am at work and cannot really tell what is the cause of my issue. I think tomorrow I will be able to check it,
because today I have a seminar and I won't get home before 22:00, which I will be way too exhausted.
In case I find the time to check it, I will surely let you know.
Quote from: jens on March 21, 2012, 06:43:59 AM
did you really clean your sozrce folder before building, especially remove the +.gch's in c::B's include ? They have moved to another place, but if old ones exist, they will probably be used by the compiler, what can lead to weird crashes.
A fresh svn-checkout is usually the easiest way to avoid such issues.
As far as I can see with make distclean, it removes .gch files but to be 100% I have added a find command on my script that searches the entire local repository for precompiled header files and delete them. I am anxiously waiting for it to finish and I will let you know after a few minutes.
I think I may have found a small, insignificant bug...
If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.
(http://img20.imageshack.us/img20/3025/cbsmall.png)
I am using the 11 February 2012 build (7789) on windows 7.
It also does the same on my Linux machine with build 7899.
Quote from: Paul_Wortmann on March 31, 2012, 08:16:30 AM
I think I may have found a small, insignificant bug...
If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.
(http://img20.imageshack.us/img20/3025/cbsmall.png)
I am using the 11 February 2012 build (7789) on windows 7.
It also does the same on my Linux machine with build 7899.
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/
Thank you.
Quote from: ollydbg on March 31, 2012, 09:05:56 AM
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/
That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.
I look into it.
Quote from: jens on March 31, 2012, 09:10:15 AM
Quote from: ollydbg on March 31, 2012, 09:05:56 AM
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/
That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.
I look into it.
Oh, You are correct, thanks.
Quote from: jens on March 31, 2012, 09:10:15 AM
Quote from: ollydbg on March 31, 2012, 09:05:56 AM
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/
That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.
I look into it.
Works fine here.
Can you create a small file, where this occurs and send it me via mail ( my_nickname at codeblocks dot org ) , or attach it here ?
I included files as requested that exhibit this behavior. "rs232.cpp"
Quote from: Paul_Wortmann on March 31, 2012, 02:57:04 PM
I included files as requested that exhibit this behavior. "rs232.cpp"
It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
My guess, is that scintilla treats the double-colon with the following tilde as one word.
So if you uncheck "Whole words only", it should work
Quote from: jens on March 31, 2012, 04:20:10 PM
Quote from: Paul_Wortmann on March 31, 2012, 02:57:04 PM
I included files as requested that exhibit this behavior. "rs232.cpp"
It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
My guess, is that scintilla treats the double-colon with the following tilde as one word.
So if you uncheck "Whole words only", it should work
I adjusted the setting as you indicated and am now able to highlight the destructor too.
Thank you very much, Jens. :)
Hi,
I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type
Regards,
VinniPuh.
Quote from: VinniPuh on April 03, 2012, 10:11:23 AM
Hi,
I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type
Regards,
VinniPuh.
Hi, many thanks.
I will fix them.
EDIT: Here is the candidate change.
/** Return (peek) the previous character */
wxChar PreviousChar() const
{
if ( ((m_TokenIndex - 1) < 0) || (m_BufferLen==0) ) // (m_TokenIndex - 1) >= m_BufferLen can never be true
return 0;
return m_Buffer.GetChar(m_TokenIndex - 1);
};
Here:
(m_TokenIndex - 1) < 0
The left is unsigned int, so its result is always >=0.
The only right case is (m_TokenIndex==0), right?
The next issue:
m_TokenIndex - 2 >= 0
So, it need to change to
m_TokenIndex >= 2Then
((m_TokenIndex - numBackslash) >= 0)
should be change to
m_TokenIndex >= numBackslashForth issue:
id = (cmb->GetCount() - 1) < 0 ? 0 : (cmb->GetCount() - 1);should change to:
cmb->GetCount() < 1The last issue:
size_t TokensTree::FindMatches(const wxString& s, TokenIdxSet& result, bool caseSensitive, bool is_prefix, short int kindMask)
{
result.clear();
std::set<size_t> lists;
int numitems = m_Tree.FindMatches(s, lists, caseSensitive, is_prefix);
if (!numitems)
return 0;
// now the lists contains indexes to all the matching keywords
// first loop will find all the keywords
for (std::set<size_t>::iterator it = lists.begin(); it != lists.end(); ++it)
{
TokenIdxSet* curset = &(m_Tree.GetItemAtPos(*it));
// second loop will get all the items mapped by the same keyword,
// for example, we have ClassA::foo, ClassB::foo ...
if (curset)
{
for (TokenIdxSet::iterator it2 = curset->begin(); it2 != curset->end(); ++it2)
{
Token* token = at(*it2);
if ( token
&& ( (kindMask == tkUndefined)
|| (token->m_TokenKind & kindMask) ) )
result.insert(*it2);
}
}
}
return result.size();
}
If I remember correct, the function parameter "short int" should be changed to Enum TokenKind type.
Quote from: ollydbg on April 03, 2012, 10:58:06 AM
Here:
(m_TokenIndex - 1) < 0
The left is unsigned int, so its result is always >=0.
The only right case is (m_TokenIndex==0), right?
I would do this differently (to improve readability) and change if clause to check for the opposite:
/** Return (peek) the previous character */
wxChar PreviousChar() const
{
if ( (m_TokenIndex > 0) && (m_BufferLen > 0) ) // m_TokenIndex > m_BufferLen can never be true
return m_Buffer.GetChar(m_TokenIndex - 1);
return 0;
};
The rest seems OK.
Ok, committed the fix. Thanks.
Quote
Revision: 7917
Author: ollydbg
Date: 2012-4-4 9:08:11
Message:
- fix log errors when comparing unsigned int with int, see: http://forums.next.codeblocks.org/index.php/topic,15945.msg109050.html#msg109050 (Thanks VinniPuh)
-------------------------------
M : /trunk/src/plugins/codecompletion/parser/tokenizer.cpp
M : /trunk/src/plugins/codecompletion/parser/tokenizer.h
M : /trunk/src/plugins/codecompletion/parser/tokenstree.cpp
M : /trunk/src/plugins/codecompletion/parser/tokenstree.h
M : /trunk/src/plugins/scriptedwizard/wizpage.cpp
Oh, I found a typo in the log message. The "log" should be "logic", can it be fixed? (svn: change log message does not work).
Quote from: ollydbg on April 04, 2012, 08:18:49 AM
Oh, I found a typo in the log message. The "log" should be "logic", can it be fixed? (svn: change log message does not work).
As Yiannis didn't find the time to implement this yet, no. :-(