Announcement

Collapse
No announcement yet.

Bug in PB/DLL 6.0 Compiler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clay Clear
    replied
    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/

    Leave a comment:


  • Lance Edmonds
    replied
    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:
    Code:
    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>

    Leave a comment:


  • Clay Clear
    replied
    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).]

    Leave a comment:


  • Chris Boss
    replied
    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.


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

    Leave a comment:


  • Clay Clear
    started a topic Bug in PB/DLL 6.0 Compiler

    Bug in PB/DLL 6.0 Compiler

    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).]
Working...
X