Loading ...
Sorry, an error occurred while loading the content.

int64 question

Expand Messages
  • Karsten Wolf
    Hi folks, as far as this project went untill now it was all non-intrusive. Every change is ifdeffed and the whole package can be switched off with a recompile.
    Message 1 of 5 , May 13, 2006
    • 0 Attachment
      Hi folks,

      as far as this project went untill now it was all non-intrusive.
      Every change is ifdeffed and the whole package can be switched off
      with a recompile.

      Now the fun begins.

      Throughout the sources there is a hidden assumption that the maximum
      size of a number is 4 bytes ( a long). Most obviously in
      stringtonumber() which returns a long.

      Another of these places is langscan.c:parsepopnumber() which makes
      sure a constant in a script gets into a long. After tweaking
      parsepopnumber() for int64, the compiler accepts longlongint values
      in scripts.

      Now I'm a bit stuck:

      if I have a sint64 with the value of 1 and do a

      s = s + 2147483648

      that number is LONG_MAX+1, a value previously rejected, the result I
      get is
      -2147483647
      which is LONG_MIN+1.

      So somehow the arithmetic with longerthanlong values coerces back to
      long.


      Any pointers?

      -karsten
    • Andre Radke
      ... How did you determine this? If you check the return value of the above addition explicitly with the UserTalk typeOf operator, what type does it indicate
      Message 2 of 5 , May 13, 2006
      • 0 Attachment
        Karsten Wolf wrote:
        >Now I'm a bit stuck:
        >
        >if I have a sint64 with the value of 1 and do a
        >
        >s = s + 2147483648
        >
        >that number is LONG_MAX+1, a value previously rejected, the result I
        >get is
        >-2147483647
        >which is LONG_MIN+1.
        >
        >So somehow the arithmetic with longerthanlong values coerces back to
        >long.

        How did you determine this?

        If you check the return value of the above addition explicitly with
        the UserTalk typeOf operator, what type does it indicate for the
        result?

        If you put a breakpoint on the longlongintvaluetype case in addvalue
        (langvalue.c:6824), does it set vreturned to the value you expect?

        If you put a breakpoint on longlonginttostring, does theInt contain
        the proper result of the previous calculation? Does the function
        produce the proper output string?

        -Andre



        --
        Andre Radke + http://spicynoodles.net/
      • Karsten Wolf
        Hallo Andre, ... via usertalk stack outline & an enhanced version of my test script. The type didn t change. ... Good ideas. Unfortunately these have to wait
        Message 3 of 5 , May 14, 2006
        • 0 Attachment
          Hallo Andre,

          > How did you determine this?
          via usertalk stack outline & an enhanced version of my test script. The type didn't change.

          > If you check the return value of the above addition explicitly with
          > the UserTalk typeOf operator, what type does it indicate for the
          > result?

          > If you put a breakpoint on the longlongintvaluetype case in addvalue
          > (langvalue.c:6824), does it set vreturned to the value you expect?

          > If you put a breakpoint on longlonginttostring, does theInt contain
          > the proper result of the previous calculation? Does the function
          > produce the proper output string?

          Good ideas.

          Unfortunately these have to wait 'till tomorrow. I'm traveling and forgot the power adapter for my laptop :-(

          -karsten
        • Karsten Wolf
          Hi Andre, second try. ... I did. Am 13.05.2006 um 21:23 schrieb Andre Radke: ... Before and after the malicious addition it returns comp which is the correct
          Message 4 of 5 , May 15, 2006
          • 0 Attachment
            Hi Andre,

            second try.



            regarding style:
            > Actually, I thought Karsten had started this, but it doesn't really
            > matter who did.
            I did.


            Am 13.05.2006 um 21:23 schrieb Andre Radke:
            ...
            > If you check the return value of the above addition explicitly with
            > the UserTalk typeOf operator, what type does it indicate for the
            > result?
            Before and after the malicious addition it returns 'comp' which is
            the correct value.

            >
            > If you put a breakpoint on the longlongintvaluetype case in addvalue
            > (langvalue.c:6824), does it set vreturned to the value you expect?
            No. The value is already truncated to long here.

            The section looks like this (please ignore the current design of
            setlonglongintvalue; that will change):

            case longlongintvaluetype:
            case longdatetimevaluetype:
            {
            Handle h;
            tylonglongint n = **v1.data.longlongintvalue +
            **v2.data.longlongintvalue;

            // this is unsafe as hell
            newhandle(sizeof(tylonglongint), &h);

            sethandlecontents(&n, sizeof(tylonglongint), h);

            fl = setlonglongintvalue (h, vreturned);
            break;
            }

            According to the debugger:

            **v1.data.longlongintvalue = 1

            **v2.data.longlongintvalue = -2147483648

            The second value should be 2147483648.


            The current callstack:
            #0 0x000bd8a4 in addvalue at langvalue.c:6824
            #1 0x000bcd3c in assignordeletevalue at langvalue.c:6475
            #2 0x000bd03c in modifyassignvalue at langvalue.c:6563
            #3 0x0010b404 in evaltree at langevaluate.c:1698
            #4 0x0010bdc0 in evaluatetree at langevaluate.c:1908
            #5 0x0010c164 in evaluatelist at langevaluate.c:2073
            #6 0x000c1adc in langfunctioncall at langvalue.c:8771
            #7 0x000c25a8 in langhandlercall at langvalue.c:9266
            #8 0x000c2ad8 in functionvalue at langvalue.c:9436
            #9 0x0010b25c in evaltree at langevaluate.c:1680
            #10 0x0010bdc0 in evaluatetree at langevaluate.c:1908
            #11 0x0010c164 in evaluatelist at langevaluate.c:2073
            #12 0x0010b9fc in evaltree at langevaluate.c:1809
            #13 0x0010bdc0 in evaluatetree at langevaluate.c:1908
            #14 0x0010c164 in evaluatelist at langevaluate.c:2073
            #15 0x001173c4 in langruncode at lang.c:1152
            #16 0x0007653c in processruncode at process.c:2594
            #17 0x00076d98 in processtimeslice at process.c:2925
            #18 0x00076e74 in oneshotthreadmain at process.c:2967
            #19 0x90bee06c in InvokeThreadEntryUPP
            #20 0x90bedc8c in CooperativeThread
            #21 0x9002ba68 in _pthread_body


            > If you put a breakpoint on longlonginttostring, does theInt contain
            > the proper result of the previous calculation? Does the function
            > produce the proper output string?
            It produces the right wrong value ;-) To be clear: it gets the
            -2147483647 in theInt.
            longlonginttostring() was at least tested with the extreme values
            when creating a number (0, LLONG_MIN, LLONG_MAX) and was so far ok
            for me.

            I gave an itch that the coercion takes place during compile time.
            That's when the breakpoint in parsepopnumber() is triggered. OTOH we
            are talking about valuerecords here, it shouldn't matter...


            -karsten
          • Karsten Wolf
            Hi folks, On 13.05.2006 um 19:25 I wrote: ... this was of course self-made. I accidentally switched a #ifdef #else #endif sequence. As a result parsepopnumber
            Message 5 of 5 , May 15, 2006
            • 0 Attachment
              Hi folks,


              On 13.05.2006 um 19:25 I wrote:
              ...
              > if I have a sint64 with the value of 1 and do a
              >
              > s = s + 2147483648
              >
              > that number is LONG_MAX+1, a value previously rejected, the result I
              > get is
              > -2147483647
              > which is LONG_MIN+1.

              this was of course self-made. I accidentally switched a #ifdef #else
              #endif sequence. As a result parsepopnumber always returned a long...
              and the kernel was so well behaved.

              Now that parsepopnumber() always returns a longlonginttype the kernel
              starts smoking in new ways that need examination.


              -karsten
            Your message has been successfully submitted and would be delivered to recipients shortly.