To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	insline() bug?
Date:	Thu, 02 Feb 95 08:31:51 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

I was porting some code from Turbo C, when I bumped into something
which looks like a bug in gppconio.c (function insline()):

*** /bin/pak/amtemp/gppconio.c	Sun May  1 20:55:54 1994
--- ./gppconio.c	Wed Feb  1 22:42:28 1995
*************** void insline(void)
*** 429,445 ****
    nbytes = (right-left+1)*2;
    bot = txinfo.winbottom-1;
    fill = ' ' | (ScreenAttrib << 8);
!   while(bot > row+1)
      {
        movedata(_go32_conventional_mem_selector(), VIDADDR(bot-1, left),
                 _go32_conventional_mem_selector(), VIDADDR(bot, left),
                 nbytes);
        bot--;
      }
!   if (row < txinfo.winbottom -1)
!     {
!       fillrow(row+1,left,right,fill);
!     }
  }
  
  
--- 429,442 ----
    nbytes = (right-left+1)*2;
    bot = txinfo.winbottom-1;
    fill = ' ' | (ScreenAttrib << 8);
!   while(bot > row)
      {
        movedata(_go32_conventional_mem_selector(), VIDADDR(bot-1, left),
                 _go32_conventional_mem_selector(), VIDADDR(bot, left),
                 nbytes);
        bot--;
      }
!   fillrow(row,left,right,fill);
  }
  
  
The original code moved down one line less than it should (row is
0-based, i.e., it is 0 for the topmost screen line).  Also, the
call to fillrow() which blanks the newly-inserted line originally
didn't do it if you'd call insline at the last screen line (row
equals windowbottom-1), which also seems like a bug.  Am I missing
something here, or is this indeed a bug?  Would somebody out there
who uses insline() in a working program, or has enough courage to
decide just by looking at the source, please check this?

Also, that while-loop seems like a gross inefficiency: why not just
movedata() it all in one swell whoop?  The data is contiguous, right?

- Raw text -