Mail Archives: djgpp/1995/02/02/05:27:06
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 -