another bug in vi + fix

another bug in vi + fix

Post by Michael Gre » Mon, 02 Jul 1990 17:14:00




Quote:>I noticed the following strange behavior of vi and, while it's not exactly
>a critical problem, I am curious as to whether vi is flawed, or my
>understanding of the way vi does searches is flawed.

>Consider the following three lines of text:

>loog loog loog loog loog loog
>loog loog loog loog loog loog
>loog loog loog loog loog loog

>Now search for loog using '/loog<cr>' followed by 'n' as required. Vi will
>stop the cursor on each word in the three lines. Fine so far. Now search
>using '/l.*g<cr>' and 'n'. Vi will stop at the first position of each line.
>This, or so I am told, is because vi matches the longest possible pattern,
>and the whole line matches, so the next match is on the next line. Fair
>enough. Now the buggy part.  Position the cursor on some character other
>than the first one on any of those lines. Then do the '/l.*g<cr>'. I would
>expect it to stop at the next occurance of 'l' on that line. It does not.
>It will stop at the first position of the next line. Anyone care to
>speculate why? And is that a correct thing for it to do?

Here I present a fix. If the fix breaks something else please let me know.
I tried it only with a few commands, of course.

Diagnosis:
        Vi executes a loop to find the next match on the line if the cursor
        stands somewhere on the line. First it looks, if there is a match
        on the line, then it tries matches until it finds the first match
        after the current position.
        This is rather strange for forward search, but it makes sense
        for backward search (inverted of course).

Therapy:
        Omit the loop. We already know where we are in the line.
        Apply the following fix.

*** ex_addr.c.old       Wed Jul 27 15:32:04 1988
--- ex_addr.c   Wed Jul 27 15:18:35 1988
***************
*** 193,204 ****
                        addr = dot;
                        if (inline && execute(0, dot)) {
                                if (c == '/') {
!                                       while (loc1 <= inline) {
!                                               if (loc1 == loc2)
!                                                       loc2++;
!                                               if (!execute(1))
!                                                       goto nope;
!                                       }
                                        break;
                                } else if (loc1 < inline) {
                                        char *last;
--- 193,201 ----
                        addr = dot;
                        if (inline && execute(0, dot)) {
                                if (c == '/') {
!                                       loc2 = inline + 1;
!                                       if (!execute(1))
!                                               goto nope;
                                        break;
                                } else if (loc1 < inline) {
                                        char *last;

Absorb, apply and enjoy,

        -mg
--
+------------------------------------------------------------------------------+
| UUCP:  ...!uunet!unido!sbsvax!greim   | Michael T. Greim                     |



| Phone: +49 681 302 2434               | D-6600 Saarbruecken 11, West Germany |
+------------------------------------------------------------------------------+
| # include <disclaimers/std.h>                                                |
+------------------------------------------------------------------------------+

 
 
 

1. SUMMARY: SVR4: bugs and bug fixes

About two weeks ago I posted a request if SVR4 developers  should
cooperate  and  how  this  could  be  done.  Until  now  I got 19
responses, including  Intel,  AT&T,  Sony,  Commodore,  Generics,
Apple etc. They all express the same feelings and wishes:

Something has to be done to avoid reinventing the wheel again and
again.

Let's give it a try: I have set up a mailing list where everybody
who is interested has a  forum  to  communicate  with  other  de-
velopers who are working on SVR4.

If you are willing to share your knowledge about  SVR4  bugs  and
how to fix them or simply want to know about "known" bugs you are
welcome to join this list. To do so please send mail to


saying "please add me to the SVR4 mailing list". You should
include in this message:

        * your full name
        * your mail address
        * the name of the company you are working for
        * a statement if you have a source licence for SVR4 or not

This list is intended primarily for SVR4 developers - people  who
have access to the full source code whose job it is to trace down
and  fix  bugs.  So  if  you  are just an ordinary user (no flame
intended here) - *PLEASE* think twice if you really  need  to  be
put on this list (you will not be able to apply a fix if you have
no  source  code).  From  time  to time I will try to repost this
advertisement to comp.bugs.sys5 as  well  as  a  summary  of  the
traffic in the mailing list.

Wolfgang

==================================================================
Name    :                                            Wolfgang Denk
Company :  PCS GmbH, Pfaelzer-Wald-Str. 36, 8000 Munich W-Germany.
UUCP    :                                 ...uunet!unido!pcsbst!wd

###################################################################
#  "UNIX was not designed to stop you from doing stupid things,   #
#   because that would  also stop you from doing clever things."  #
#   -- Doug Gwyn                                                  #
###################################################################

2. IPC Implement LPC (local procedure calls)

3. 0.99pl8 kernel bug -fix (= no kernel bug)

4. tar basics

5. SVR4: bugs and bug fixes

6. How to port ??

7. Netscapes libraries fix / Does not fix java bugs though

8. Need heap (memory) manager

9. Slab cache name fixes / reiserfs boot bug fix.

10. linux.fix.temp: Linux bug fix report template

11. PATCH: 2.5.40 Fix stupid scsi setup bug in 53c406, fix addressing

12. Help me to fix the vi and man under kernel 1.3.20

13. Is there a fix for problem w vi sessions not dying when parent dies?