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

[patch] fixed undefined behavior found with IOC tool

Expand Messages
  • Dominique Pellé
    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
    Message 1 of 7 , Nov 4, 2012
    • 0 Attachment
      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

      --
      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
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.