Message-Id:	<199809011559.RAA36082@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>, djgpp AT delorie DOT com,
	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Date:	Tue, 1 Sep 1998 18:03:18 +0300
MIME-Version:	1.0
Subject:	Re: Little bug in RHIDE
In-reply-to:	<m0zDrfo-000S4wC@inti.gov.ar>
References:	<199809011326 DOT PAA53504 AT ieva06 DOT lanet DOT lv>

From:           	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Subject:        	Re: Little bug in RHIDE

> > 
> > It is real bug in RHIDE (both 1.4 and 1.4.5, I tested only latest)
> > 
> > The problem is that TFileInfoPane::draw () in such situation writes 
> > to TDrawBuffer more data than allowed width (currenty 132 for 
> > DJGPP version and 1024 for Linux one: see 
> > tvision/include/tvconfig.h for definition of maxViewWidth)
> > 
> > I see 2 possible solutions:
> >    - enlarge maxViewWidth in tvconfig.h (as I understand Win95     
> >      does not allow filenames larger than 260 bytes however I 
> >       haven't tested that)
> >    - check for data size to be written into TDrawBuffer
> 
> I think the best is a check in the TFileInfoPane::draw. Enlarging the 
> maxViewWidth is a very bad idea because it makes *all* the buffers greater 
> and I don't see any good reason for it. The 132 is just because that's the 
> maximun number of columns supported, perhaps it should be moved to 160 
> because SVGAText can setup such a mode, but not more.
> I must evaluate the TDrawBuffer alternative with more detail.

Maybe it's better to check the range in member functions of class
TDrawBuffer. That would avoid need to check all places where 
TDrawBuffer is being used. Last available version of SETEDIT also
suffers from this problem as uses same sources of TVision as I 
looked

> BTW, yesterday I was testing RHIDE 1.4.5.1 compiled here and I was able to 
> debug the editor without problems. I used gdb 4.16: What did you used? Your 
> patches changes the makefiles to search for 4.17, are you really using it? I 
> changed it back to 4.16. 

Sorry no. I'm using gdb-4.17 for Linux version and still gdb-4.16 for 
DJGPP as I don't have working gdb-4.17 for DJGPP. I generated 
diffs on Linux and the sources are currently not synchronized with 
ones on Win95 partition. There were also fixes to get RHIDE 
compiled without warnings with upcomming egcs-1.1 (I don't want 
to remove compiler option -Werror).

> I want to fix other common problems in RHIDE and release it.

Are You interested to check this all with egcs-1.1 prerelease. 

C:\>gcc -v
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/egcs-291.56/specs
gcc version egcs-2.91.56 19980829 (egcs-1.1 pre-release)

Perhaps I can make binary archives available if You are interested.
(Warning: they are build using slightly patched djdev202 and for 
djdev202, however only small hacking should be needed to get 
exceptions working with djdev201 as I didn't include crtf.o because
it is no more needed with djdev202)

Andris

- Raw text -