Announcement

Collapse
No announcement yet.

Bug in PB/DLL 6.0 Compiler

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

  • 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]om
    http://www.v3space.com/a/a39/202/

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

  • #2
    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.


    ------------------
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #3
      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).]

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment


        • #5
          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/

          Comment

          Working...
          X