NO

Author Topic: bsearch  (Read 11416 times)

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: bsearch
« Reply #15 on: March 09, 2013, 11:20:24 PM »
PLEASE guys, keep it down a bit, this is not the place for any personal rants/attacks...

As for the issue at hand, debugging C programs with a CPU level debugger for a case like this is IMHO as well nonsense. And the build-in debugger will work just fine for the task to track down the issue of the OP.
And for me personal, I don't see anything wrong with the font in the register window/tab of the debugger, though possibly using different colors for register name and their values might be a possible improvement.
Showing the CPU flags for plain C programs/libraries is pretty much useless, only when directly working with assembler sources this could eventually be an advantage...

Ralf

Offline jj2007

  • Member
  • *
  • Posts: 536
Re: bsearch
« Reply #16 on: March 09, 2013, 11:41:51 PM »
Ralf,

Even with my glasses I can't read that tiny font, so it is an issue.

In another thread on GetOpenFileName there is something going wrong deep inside the API - no problem for Olly but I doubt it would be easy with the in-built debugger. I'd be curious to test it (after all, how often can you find a real Windows bug?), but the GetOpenFileName misbehaviour seems almost impossible to reproduce...

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: bsearch
« Reply #17 on: March 10, 2013, 04:32:32 AM »
Ralf,

Even with my glasses I can't read that tiny font, so it is an issue.
I am running all my screens at 1280x1024 or higher, with standard Windows font sizes everywhere and I don't have a problem at all. No glasses for me...
And beside that, as mentioned, when debugging C programs (or pretty much any high level language, Pascal, Fortran, C++, C#, just as examples) it is very rare that you need to go down to the CPU level at all. I am certain that 99.999% of all issues are in fact on the level of that high-level language...
Quote
In another thread on GetOpenFileName there is something going wrong deep inside the API - no problem for Olly but I doubt it would be easy with the in-built debugger. I'd be curious to test it (after all, how often can you find a real Windows bug?), but the GetOpenFileName misbehaviour seems almost impossible to reproduce...
Weird issue indeed and that this problem is reproducible with some standard Windows programs (like Notepad) seems to indicate that this is in fact a problem within the Windows API, not likely an issue with any program that is using it. And to track down, it would require debugging the code of the Windows API, at the level of the language it is written in (and I doubt that this is assembler in this case). That leaves pretty much the ball in Microsoft's court, if they would even remotely be interested to tracking this down...

Ralf

Offline jj2007

  • Member
  • *
  • Posts: 536
Re: bsearch
« Reply #18 on: March 10, 2013, 10:26:47 AM »
The text is not displayed correctly because you are asking the WINDOWS CONSOLE to display multiple languages (i.e. codepages) simultaneously  and it can't do that. If you actually knew anything about Windows Unicode, you would know that.
 
Look at the source code... see the two calls MultiByteToWideChar() and WideCharToMultiByte() ?
Those are windows API calls

Tater, you are confused. The windows console has no problems displaying multiple languages - this is copied directly from the console:

UTF-8 text file created, now reading & printing
Введите текст здесь
Нажмите на эту кнопку
Добро пожаловать
أدخل النص هنا
دفع هذا الزر
مرحبا بكم
在這裡輸入文字
按一下這個按鈕
歡迎

And it has nothing to do with "multiple codepages", it's just one codepage, UTF-8.

Demo attached (Asiatic fonts need to be installed, and user must set Lucida Console, as usual). In case you know how to use a CPU level debugger, you may find references to  MultiByteToWideChar() and WideCharToMultiByte, too.

Take care,
jj

P.S.: Apologies that the source is Assembler, not C. Open the *.asc file in WordPad. I hope it's self-explanatory. These are the lines that open the file, read the strings and display them in the console:
  Recall "Utf8.txt", L$()
  SetCpUtf8
  For_ ebx=0 To eax-1
        Print L$(ebx), CrLf$
  Next

« Last Edit: March 10, 2013, 10:32:03 AM by jj2007 »

CommonTater

  • Guest
Re: bsearch
« Reply #19 on: March 10, 2013, 12:41:48 PM »
Tater, you are confused.

Not any more... 
 
Because of you the price of generosity has become too high.
 
« Last Edit: March 10, 2013, 01:31:25 PM by CommonTater »

tpekar

  • Guest
Re: bsearch
« Reply #20 on: March 11, 2013, 03:04:18 PM »
timovl,

Thanks for the fix.  It worked.  Apparently bsearch is looking for the address of a pointer.  Is that like a pointer to a pointer? 

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: bsearch
« Reply #21 on: March 11, 2013, 10:04:35 PM »
Apparently bsearch is looking for the address of a pointer.  Is that like a pointer to a pointer?

No, it is just the memory address where the value of the pointer is saved.
It is not the value of the pointer.

Think of it as the difference of by value and by reference.

If you have a variable pointer with the value 1234 located at address 6789 the following will apply for the argument passed to a function:

1) pointer ... the value 1234 will be passed to the function
2) &pointer ... the address 6789 will be passed to the function
---
Stefan

Proud member of the UltraDefrag Development Team