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

RE: vim 6.3 errors on sunos 4.1.3_U1

Expand Messages
  • Soh Tk-r28629
    ... I don t know if strcmp() can be replace so easily judging from it s manpages. I have also tried to link in libc.a supplied with the patch instead, assuming
    Message 1 of 10 , Aug 8, 2004
      > -----Original Message-----
      > >The bug has been comfirmed. I found this in patch #101759 for SunOS
      > >4.1.3_U1 (similar bug for 4.1.3):
      > >
      > > 1074633 strcmp gets bad result when 0x80 char put in string
      > >
      > >I downloaded the patch and it did fix the problem I have with vim.
      > >Since I can't apply the patch to all the Sun boxes (of our
      > >manufacturing equipments), I wonder if we can just change
      > K_SPECIAL to something else. I've changed it to 0x81, which seemed to work so far.
      > >
      > >
      > When patch can't be installed, the safe solution is is to
      > link with home-grown strcmp.o (code untested, but seems ok to me):
      >
      > /* strcmp.c - work around libc strcmp() bug */
      > int strcmp(const char* p, const char* q) { /* untested */
      > while(*p == *q && *p != 0) /* untested */
      > p++, q++; /* untested */
      > return *p - *q; /* untested */
      > }

      I don't know if strcmp() can be replace so easily judging from it's manpages. I have also tried to link in libc.a supplied with the patch instead, assuming it's okay to do so. And so far it seemed to be working fine.

      IMO, this bug (and it's fix) should at least be mentioned in the README/INSTALL/Makefile.
    • Craig Barkhouse
      ... From: Soh Tk-r28629 To: Yakov Lerner Cc: ; Sent: Monday, August 09,
      Message 2 of 10 , Aug 8, 2004
        ----- Original Message -----
        From: "Soh Tk-r28629" <TKSoh@...>
        To: "'Yakov Lerner'" <qlerner@...>
        Cc: <vim@...>; <vim-dev@...>
        Sent: Monday, August 09, 2004 12:04 AM
        Subject: RE: vim 6.3 errors on sunos 4.1.3_U1


        > > -----Original Message-----
        > > >The bug has been comfirmed. I found this in patch #101759 for SunOS
        > > >4.1.3_U1 (similar bug for 4.1.3):
        > > >
        > > > 1074633 strcmp gets bad result when 0x80 char put in string
        > > >
        > > >I downloaded the patch and it did fix the problem I have with vim.
        > > >Since I can't apply the patch to all the Sun boxes (of our
        > > >manufacturing equipments), I wonder if we can just change
        > > K_SPECIAL to something else. I've changed it to 0x81, which seemed to
        work so far.
        > > >
        > > >
        > > When patch can't be installed, the safe solution is is to
        > > link with home-grown strcmp.o (code untested, but seems ok to me):
        > >
        > > /* strcmp.c - work around libc strcmp() bug */
        > > int strcmp(const char* p, const char* q) { /* untested */
        > > while(*p == *q && *p != 0) /* untested */
        > > p++, q++; /* untested */
        > > return *p - *q; /* untested */
        > > }
        >
        > I don't know if strcmp() can be replace so easily judging from it's
        manpages.

        Why not? It's a pretty simple function.

        I don't know how difficult this is to do, but... Maybe the configure script
        should have a test to see if strcmp() works in the critical scenario (i.e.
        strings containing 0x80). Then, depending on an #ifdef, either override
        strcmp() or not.
      • George V. Reilly
        ... The mind boggles how they screwed up as simple a function as strcmp. -- A small block will do, 5 or 6 pounds. -- Spock on platinum. (Get Witty
        Message 3 of 10 , Aug 9, 2004
          Soh Tk-r28629 wrote:

          >>-----Original Message-----
          >>
          >>
          >>>The bug has been comfirmed. I found this in patch #101759 for SunOS
          >>>4.1.3_U1 (similar bug for 4.1.3):
          >>>
          >>> 1074633 strcmp gets bad result when 0x80 char put in string
          >>>
          >>>
          The mind boggles how they screwed up as simple a function as strcmp.

          --
          A small block will do, 5 or 6 pounds.
          -- Spock on platinum.
          (Get Witty Auto-Generated Signatures from http://SmartBee.org)
          George V. Reilly george@...
          http://george.reilly.org/
          Read my blog: http://weblogs.asp.net/george_v_reilly/
        • Antoine J. Mechelynck
          ... IMHO, a function like strcmp() should not be emulated in C because of speed constraints. If you want to rewrite it, OK, but do it in assembly language (and
          Message 4 of 10 , Aug 9, 2004
            Craig Barkhouse <cabarkho@...> wrote:
            > ----- Original Message -----
            > From: "Soh Tk-r28629" <TKSoh@...>
            > To: "'Yakov Lerner'" <qlerner@...>
            > Cc: <vim@...>; <vim-dev@...>
            > Sent: Monday, August 09, 2004 12:04 AM
            > Subject: RE: vim 6.3 errors on sunos 4.1.3_U1
            >
            >
            > > > -----Original Message-----
            > > > > The bug has been comfirmed. I found this in patch #101759 for
            > > > > SunOS
            > > > > 4.1.3_U1 (similar bug for 4.1.3):
            > > > >
            > > > > 1074633 strcmp gets bad result when 0x80 char put in string
            > > > >
            > > > > I downloaded the patch and it did fix the problem I have with
            > > > > vim. Since I can't apply the patch to all the Sun boxes (of our
            > > > > manufacturing equipments), I wonder if we can just change
            > > > K_SPECIAL to something else. I've changed it to 0x81, which
            > > > seemed to work so far.
            > > > >
            > > > >
            > > > When patch can't be installed, the safe solution is is to
            > > > link with home-grown strcmp.o (code untested, but seems ok to me):
            > > >
            > > > /* strcmp.c - work around libc strcmp() bug */
            > > > int strcmp(const char* p, const char* q) { /* untested */
            > > > while(*p == *q && *p != 0) /* untested */
            > > > p++, q++; /* untested */
            > > > return *p - *q; /* untested */
            > > > }
            > >
            > > I don't know if strcmp() can be replace so easily judging from it's
            > > manpages.
            >
            > Why not? It's a pretty simple function.
            >
            > I don't know how difficult this is to do, but... Maybe the configure
            > script should have a test to see if strcmp() works in the critical
            > scenario (i.e. strings containing 0x80). Then, depending on an
            > #ifdef, either override strcmp() or not.

            IMHO, a function like strcmp() should not be emulated in C because of speed
            constraints. If you want to rewrite it, OK, but do it in assembly language
            (and since assembly is inherently non-portable, write a different version
            for each possible processor...). For example, on the i86 family, I believe
            that REPE CMPSB is significantly faster than the loop described above in C,
            even if you first have to do a REPNE SCASB to find the null byte.

            Regards,
            Tony.
          • George V. Reilly
            ... This fragile approach is worthwhile only if strcmp() is a major bottleneck. Most Vim operations consume minimal amounts of CPU time on a modern gigahertz
            Message 5 of 10 , Aug 9, 2004
              Antoine J. Mechelynck wrote:

              >IMHO, a function like strcmp() should not be emulated in C because of speed
              >constraints. If you want to rewrite it, OK, but do it in assembly language
              >(and since assembly is inherently non-portable, write a different version
              >for each possible processor...). For example, on the i86 family, I believe
              >that REPE CMPSB is significantly faster than the loop described above in C,
              >even if you first have to do a REPNE SCASB to find the null byte.
              >
              >
              This fragile approach is worthwhile only if strcmp() is a major
              bottleneck. Most Vim operations consume minimal amounts of CPU time on a
              modern gigahertz processor. Even on a decade-old Sparc, rewriting strcmp
              in assembler is unlikely to yield a noticeable improvement in Vim.

              --
              Audemus jura nostra defendere...
              [Let us dare defend our rights.]
              (Get Witty Auto-Generated Signatures from http://SmartBee.org)
              George V. Reilly george@...
              http://george.reilly.org/
            • Antoine J. Mechelynck
              ... Vim admittedly spends most of its time waiting for keyboard action. But how about commands like :substitute or :helpgrep, which IIUC do quite a lot of
              Message 6 of 10 , Aug 9, 2004
                George V. Reilly <george@...> wrote:
                > Antoine J. Mechelynck wrote:
                >
                > > IMHO, a function like strcmp() should not be emulated in C because
                > > of speed constraints. If you want to rewrite it, OK, but do it in
                > > assembly language (and since assembly is inherently non-portable,
                > > write a different version for each possible processor...). For
                > > example, on the i86 family, I believe that REPE CMPSB is
                > > significantly faster than the loop described above in C, even if
                > > you first have to do a REPNE SCASB to find the null byte.
                > >
                > >
                > This fragile approach is worthwhile only if strcmp() is a major
                > bottleneck. Most Vim operations consume minimal amounts of CPU time
                > on a modern gigahertz processor. Even on a decade-old Sparc,
                > rewriting strcmp in assembler is unlikely to yield a noticeable
                > improvement in Vim.

                Vim admittedly spends most of its time waiting for keyboard action. But how
                about commands like :substitute or :helpgrep, which IIUC do quite a lot of
                string comparisons before they return to the wait-for-keyboard state? I
                maintain that whatever the gigaspeed, for something as basic as string
                comparison, you can only afford the fastest of the fast coding.

                Regards,
                Tony.
              • Bram Moolenaar
                ... A system with a strcmp() that doesn t work???? That is the most stupid bug heard off. I don t think it s worth checking for, that system is broken. Do
                Message 7 of 10 , Aug 31, 2004
                  Craig Barkhouse wrote:

                  > I don't know how difficult this is to do, but... Maybe the configure
                  > script should have a test to see if strcmp() works in the critical
                  > scenario (i.e. strings containing 0x80). Then, depending on an
                  > #ifdef, either override strcmp() or not.

                  A system with a strcmp() that doesn't work???? That is the most stupid
                  bug heard off. I don't think it's worth checking for, that system is
                  broken. Do we also need to test for bad RAM chips perhaps?

                  --
                  Two fish in a tank. One says to the other:
                  "Do you know how to drive this thing?"

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                Your message has been successfully submitted and would be delivered to recipients shortly.