Bug in PB/DLL 6.0 Compiler

[Clay Clear]

I have written some number-format conversion programs. Each one
converts between two formats. In both programs that take Hex
numbers as input, when the input number is "FFFF", the program
ALWAYS returns the maximum number that a DWORD variable can hold.
For all other input numbers, the programs work correctly.

I can only conclude that it's a bug in the compiler.

ADDENDUM: the same error occurs on ANY hex number where the high-bit
of the LOWORD of the DWORD variable is set. However, this has only
been borne out while using 4-character hex input numbers
(i.e., 8??? - F???) - I haven't tested it on numbers that use
more than 4 characters.
------------------
Clay C. Clear

[email protected]
http://www.v3space.com/a/a39/202/

[This message has been edited by Clay Clear (edited July 21, 2001).]

[Chris Boss]

Clay;

Lets see some sample code (or send it to tech support).

My gut feeling is that if only the hex value FFFF is returning
the wrong value, you made a mistake somewhere in your code, which
uses a Long rather than a DWord and the high bit is getting lost.

I doubt there is an actual bug in this instance, but lets see some
code so it can be verified.


------------------

[Clay Clear]

Figured it out! With the PB/DLL Compiler, when you use the VAL
function to convert hex numbers to a decimal number that is stored
in a DWORD variable, you've got to pad the hex number with leading
zeroes. The same with converting binary inputs.


------------------
Clay C. Clear

[email protected]
http://www.v3space.com/a/a39/202/

[This message has been edited by Clay Clear (edited July 21, 2001).]

[Lance Edmonds]

Clay, you are experiencing the differences between signed or unsigned values and how PowerBASIC translates between them.

In your code, you assigned the (Signed INTEGER) value &HFFFF to a DWORD. It is an INTEGER value because without an explicit type specifier, PowerBASIC fits it into the closest variable type, in this case INTEGER. Also, the high-order bit is set, which means the value is signed.

Therefore, as you probably know, thre numeric literal &HFFFF is the same as -1%.

However, when you assign -1% to a DWORD, the value gets translated to the DWORD value &H0FFFFFFFF.

You'll note the subtle way I represented that last value: it included a leading zero - and this is how you can determine/specify whether the value is signed or unsigned (or you can give the value an explicit type-specifier)

For example:

var = &H0FFFF  ' unsigned
var = &HFFFF   ' signed (the high order bit is set)
var = &HFFFF?? ' unsigned (uses a type specifier)
var = &HFFFF%  ' signed
 
a$ = "FFFF"
var = VAL("&H0" + A$) ' unsigned
var = VAL("&H" + a$)  ' signed

The same effect can be observed with Binary values, etc.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Clay Clear]

Lance,

Thanks a lot! That DID help! I'm familiar with the signed/unsigned
stuff, BUT, I had assumed that the Compiler would take care of that
internally when I assigned the VAL("&HFFFF") to a DWORD variable.
I declared the DWORD variable as a DWORD in the source code's
header.

Just a sec - am going to re-read your posting - it's quite likely
that you addressed that issue, and I've already forgotten what you said.

Thanks again!


------------------
Clay C. Clear

[email protected]

http://www.v3space.com/a/a39/202/