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

Re: [patch] fixed undefined behavior found with IOC tool

Expand Messages
  • Dominique PellĂ©
    ... Attached is an updated patch to fix one more undefined signed integer overflow at hashtab.c:457. Regards -- Dominique -- You received this message from the
    Message 1 of 7 , Nov 4, 2012
    • 0 Attachment
      Dominique Pellé wrote:

      > Hi
      >
      > I ran "make test" with vim-7.3.712 compiled with IOC
      > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
      > overflows, which behave in undefined way according to
      > the C standard. Only unsigned integer is guaranteed to
      > behave in a predictable way. IOC found a few bugs:
      >
      > CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
      > Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
      > right (int32): 1608754829
      >
      > CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
      > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
      > right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
      > : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
      > left (
      >
      > CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
      > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
      > right (int32): 64086
      >
      > Attached patch fixes them.
      >
      > There is one more undefined behavior operation (float divide by 0 which is also
      > undefined in C). Fixing it would require to use the INFINITY macro I think
      > but it's C99 macro and Vim needs to compile on older compilers so I
      > did not fix it:
      >
      > CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
      > Floating Division: Divisor is 0, BINARY OPERATION: left (double):
      > 1.000000 right (double): 0.000000
      >
      > It could be fixed by checking for INFINITY in autoconf.
      >
      > There might be more of such bugs: IOC is runtime checker so it only
      > checked what was executed while running "make test".
      >
      > Regards
      > -- Dominique


      Attached is an updated patch to fix one more undefined
      signed integer overflow at hashtab.c:457.

      Regards
      -- Dominique

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Bram Moolenaar
      ... The actual problem is in the standard. Having integer operations behave in an undefined way is not very useful. They should have defined uniform
      Message 2 of 7 , Nov 6, 2012
      • 0 Attachment
        Dominique Pelle wrote:

        > I ran "make test" with vim-7.3.712 compiled with IOC
        > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
        > overflows, which behave in undefined way according to
        > the C standard. Only unsigned integer is guaranteed to
        > behave in a predictable way. IOC found a few bugs:

        The actual problem is in the standard. Having integer operations behave
        in an undefined way is not very useful. They should have defined
        uniform behavior. It's the compiler writers who like these things to be
        undefined, not the users.

        > CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
        > Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
        > right (int32): 1608754829
        >
        > CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
        > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
        > right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
        > : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
        > left (
        >
        > CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
        > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
        > right (int32): 64086
        >
        > Attached patch fixes them.

        Thanks, I'll add it to the todo list.

        > There is one more undefined behavior operation (float divide by 0
        > which is also undefined in C). Fixing it would require to use the
        > INFINITY macro I think but it's C99 macro and Vim needs to compile on
        > older compilers so I did not fix it:

        Undefined? I thought divide by zero always results in INF. What
        compiler does otherwise?

        > CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
        > Floating Division: Divisor is 0, BINARY OPERATION: left (double):
        > 1.000000 right (double): 0.000000
        >
        > It could be fixed by checking for INFINITY in autoconf.
        >
        > There might be more of such bugs: IOC is runtime checker so it only
        > checked what was executed while running "make test".

        These might not be bugs, compilers often do more sensible things than
        what C99 defines. C99 is not a very good standard, it drifted away from
        the goal to make the language more useful for programmers.

        Although such a tool can find possible problems, there would also need
        to be a compiler that actually does something wrong with the code.


        --
        hundred-and-one symptoms of being an internet addict:
        21. Your dog has its own home page.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • Bram Moolenaar
        ... The actual problem is in the standard. Having integer operations behave in an undefined way is not very useful. They should have defined uniform
        Message 3 of 7 , Nov 7, 2012
        • 0 Attachment
          Dominique Pelle wrote:

          > I ran "make test" with vim-7.3.712 compiled with IOC
          > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
          > overflows, which behave in undefined way according to
          > the C standard. Only unsigned integer is guaranteed to
          > behave in a predictable way. IOC found a few bugs:

          The actual problem is in the standard. Having integer operations behave
          in an undefined way is not very useful. They should have defined
          uniform behavior. It's the compiler writers who like these things to be
          undefined, not the users.

          > CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
          > Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
          > right (int32): 1608754829
          >
          > CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
          > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
          > right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
          > : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
          > left (
          >
          > CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
          > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
          > right (int32): 64086
          >
          > Attached patch fixes them.

          Thanks, I'll add it to the todo list.

          > There is one more undefined behavior operation (float divide by 0
          > which is also undefined in C). Fixing it would require to use the
          > INFINITY macro I think but it's C99 macro and Vim needs to compile on
          > older compilers so I did not fix it:

          Undefined? I thought divide by zero always results in INF. What
          compiler does otherwise?

          > CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
          > Floating Division: Divisor is 0, BINARY OPERATION: left (double):
          > 1.000000 right (double): 0.000000
          >
          > It could be fixed by checking for INFINITY in autoconf.
          >
          > There might be more of such bugs: IOC is runtime checker so it only
          > checked what was executed while running "make test".

          These might not be bugs, compilers often do more sensible things than
          what C99 defines. C99 is not a very good standard, it drifted away from
          the goal to make the language more useful for programmers.

          Although such a tool can find possible problems, there would also need
          to be a compiler that actually does something wrong with the code.


          --
          hundred-and-one symptoms of being an internet addict:
          21. Your dog has its own home page.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Matthew Winn
          On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar ... It s useful because the alternative would require the compiler to check for overflow after every
          Message 4 of 7 , Nov 7, 2012
          • 0 Attachment
            On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar
            <Bram@...> wrote:

            > Dominique Pelle wrote:
            >
            > > I ran "make test" with vim-7.3.712 compiled with IOC
            > > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
            > > overflows, which behave in undefined way according to
            > > the C standard. Only unsigned integer is guaranteed to
            > > behave in a predictable way. IOC found a few bugs:
            >
            > The actual problem is in the standard. Having integer operations behave
            > in an undefined way is not very useful. They should have defined
            > uniform behavior. It's the compiler writers who like these things to be
            > undefined, not the users.

            It's useful because the alternative would require the compiler to
            check for overflow after every operation if the underlying hardware
            behaved differently from the standard. Almost from the beginning it
            was C's policy to prefer efficiency and put the burden of avoiding
            non-portable behaviour on the programmer rather than slow everything
            down by checking things that rarely matter.

            > > There is one more undefined behavior operation (float divide by 0
            > > which is also undefined in C). Fixing it would require to use the
            > > INFINITY macro I think but it's C99 macro and Vim needs to compile on
            > > older compilers so I did not fix it:
            >
            > Undefined? I thought divide by zero always results in INF. What
            > compiler does otherwise?

            I think it depends on the floating-point hardware, if there is any.
            I remember hearing of systems that didn't have Inf or NaN but I don't
            remember using one myself.

            --
            Matthew Winn

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Bram Moolenaar
            ... I don t know any hardware that behaves different with overflow. All CPUs just discard the upper bits. it s the software that has a problem. And then
            Message 5 of 7 , Nov 7, 2012
            • 0 Attachment
              Matthew Winn wrote:

              > On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar
              > <Bram@...> wrote:
              >
              > > Dominique Pelle wrote:
              > >
              > > > I ran "make test" with vim-7.3.712 compiled with IOC
              > > > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
              > > > overflows, which behave in undefined way according to
              > > > the C standard. Only unsigned integer is guaranteed to
              > > > behave in a predictable way. IOC found a few bugs:
              > >
              > > The actual problem is in the standard. Having integer operations behave
              > > in an undefined way is not very useful. They should have defined
              > > uniform behavior. It's the compiler writers who like these things to be
              > > undefined, not the users.
              >
              > It's useful because the alternative would require the compiler to
              > check for overflow after every operation if the underlying hardware
              > behaved differently from the standard. Almost from the beginning it
              > was C's policy to prefer efficiency and put the burden of avoiding
              > non-portable behaviour on the programmer rather than slow everything
              > down by checking things that rarely matter.

              I don't know any hardware that behaves different with overflow. All
              CPUs just discard the upper bits. it's the software that has a problem.
              And then instead of solving this in the compiler, it's left to every
              progammer to figure out.

              AFAIK the C99 standard was written mostly by compiler writers. They
              have their own view on the world and made choices that are not always
              what a programmer would do. This standardization work is often very
              boring and time consuming, which results in people who just want to get
              things done not get involved. I'm sure I will never be part of it, just
              because it takes too much time. I believe in specs that are written by
              a small team of dedicated people. And I don't believe in design by
              comittee.


              > > > There is one more undefined behavior operation (float divide by 0
              > > > which is also undefined in C). Fixing it would require to use the
              > > > INFINITY macro I think but it's C99 macro and Vim needs to compile on
              > > > older compilers so I did not fix it:
              > >
              > > Undefined? I thought divide by zero always results in INF. What
              > > compiler does otherwise?
              >
              > I think it depends on the floating-point hardware, if there is any.
              > I remember hearing of systems that didn't have Inf or NaN but I don't
              > remember using one myself.

              If the hardware doesn't support it then should the compiler take care of
              it or should every programmer know exactly what is going on and write
              bulky code to handle it? I think it's best when the compiler does it.
              Anyway, C99 does define INF and NaN, thus it must be supported, either
              with hardware or otherwise.


              --
              Q: What is the difference betwee open-source and commercial software?
              A: If you have a problem with commercial software you can call a phone
              number and they will tell you it might be solved in a future version.
              For open-source software there isn't a phone number to call, but you
              get the solution within a day.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Bram Moolenaar
              ... The actual problem is in the standard. Having integer operations behave in an undefined way is not very useful. They should have defined uniform
              Message 6 of 7 , Nov 7, 2012
              • 0 Attachment
                Dominique Pelle wrote:

                > I ran "make test" with vim-7.3.712 compiled with IOC
                > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
                > overflows, which behave in undefined way according to
                > the C standard. Only unsigned integer is guaranteed to
                > behave in a predictable way. IOC found a few bugs:

                The actual problem is in the standard. Having integer operations behave
                in an undefined way is not very useful. They should have defined
                uniform behavior. It's the compiler writers who like these things to be
                undefined, not the users.

                > CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
                > Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
                > right (int32): 1608754829
                >
                > CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
                > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
                > right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
                > : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
                > left (
                >
                > CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
                > Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
                > right (int32): 64086
                >
                > Attached patch fixes them.

                Thanks, I'll add it to the todo list.

                > There is one more undefined behavior operation (float divide by 0
                > which is also undefined in C). Fixing it would require to use the
                > INFINITY macro I think but it's C99 macro and Vim needs to compile on
                > older compilers so I did not fix it:

                Undefined? I thought divide by zero always results in INF. What
                compiler does otherwise?

                > CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
                > Floating Division: Divisor is 0, BINARY OPERATION: left (double):
                > 1.000000 right (double): 0.000000
                >
                > It could be fixed by checking for INFINITY in autoconf.
                >
                > There might be more of such bugs: IOC is runtime checker so it only
                > checked what was executed while running "make test".

                These might not be bugs, compilers often do more sensible things than
                what C99 defines. C99 is not a very good standard, it drifted away from
                the goal to make the language more useful for programmers.

                Although such a tool can find possible problems, there would also need
                to be a compiler that actually does something wrong with the code.


                --
                hundred-and-one symptoms of being an internet addict:
                21. Your dog has its own home page.

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ an exciting new programming language -- http://www.Zimbu.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              Your message has been successfully submitted and would be delivered to recipients shortly.