[Bug 2474] Program wants to call file in same directory as program, but claims it cannot find it.

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2474





------- Additional Comments From a_villacis(a)palosanto.com  2005-23-03 11:33 -------
The review for the code continues, now with the second bug.

The second problem is a cryptic "Runtime error 13 - Type mismatch" before the 
main GUI is displayed. This second problem cripples the GUI beyond usability 
(not even the menus work). Last night I traced the problem to the way an
underflowing negative float was converted into a string.

This program's GUI has two textboxes in which the integer and fractional part of
the gain are displayed. In order to fill them for the first time, the program
extracts the integer and fractional part of the value stored in the registry. 
For the fractional part, a series of truncating and rounding are performed on
the original value, followed by a floating-point subtraction. When no values
are stored in the registry (as it is on the very first run), the substraction
is supposed to yield a floating-point zero, but instead produces a very small 
negative number (something in the order of -1e-300 to -1e-400). The code 
assigns the number to the Text property of a TextBox control, which implicitly
invokes the TextBox_Change event. It is at this stage where things turn nasty.

The root cause is a difference between the way native and builtin oleaut32 
handle the conversion of a negative underflow. With a number in the range 
mentioned in the preceeding paragraph, native oleaut32 decides it is too close
to a zero, and yields the string "0". Builtin oleaut32 does the same, except 
that the negative sign is left behind, and it yields the string "-0". This
difference is significant when the code in TextBox_Change invokes a routine 
that (expecting an unsigned integer) keeps just the first character of the 
textbox string ("0" for native oleaut32, "-" for builtin oleaut32). Then a
string-to-float conversion is attempted on the string, which naturally fails
for the single dash.

The solution is to disallow negative zeroes from ever being returned from a
string-to-float conversion.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.