Author Topic: Bug: contains too many ".."! during debugging session  (Read 3802 times)

StinkyWinky

  • Guest
Bug: contains too many ".."! during debugging session
« on: November 24, 2006, 09:33:41 am »
Build: Nov 8 2006, 00:20:29 - wx2.6.3 (Windows, unicode)

During debugging, when pressing <shift><F7> in order to jump into the function, following error message is displayed:

"Codeblocks Error  The path 'K:\ErrorMng.c' contains too many ".."!"

The output of the debugger log is this:

Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: K:\_Testing\UI\TestUI\
Adding source dir: K:\
Adding file: .\TestUI.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.3
At K:/_Testing/UI/TestUI/../Cases/TstErrorMng.c:331
At K:/../../../UI/ErrorMng/ErrorMng.c:212

The caller function is located in:
K:\_Testing\UI\Cases\TstErrorMng.c

The called function is located in:
K:\UI\ErrorMng\ErrorMng.c

I don't have this kind of error with the official 1.0rc2 (dated Oct 25, 2005)

Although the nightly build version has much improvements, this is quite a show stopper to me  :(


Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Bug: contains too many ".."! during debugging session
« Reply #1 on: November 24, 2006, 02:29:13 pm »
That's an error produced by wxFileName that is entirely useless, but nevertheless shown every time you feed it a path that has at least one ".." on the filesystem root. For example K:/../../../UI/ErrorMng/ErrorMng.c would be such a candidate.

It's entirely stupid, because ".."ing on the filesystem root is perfectly legal, but that's how it is, sadly (wxFilename operates by chopping the input string by wxFILE_SEP and puking everything into an arraystring. Then it hangles up indices each time it finds a "..", and throws that error when the index becomes negative).

The only thing we can really do (apart from not using wxFileName at all, which would be the best solution) is to add a wxNullLog in that context, but for that, we'd first have to find the right one.  :?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."