Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: "Andris Pavenis" , robert DOT hoehne AT gmx DOT net Date: Tue, 1 Sep 1998 14:01:16 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Little bug in RHIDE CC: djgpp AT delorie DOT com In-reply-to: <199809011559.RAA36082@ieva06.lanet.lv> References: Precedence: bulk "Andris Pavenis" wrote: > > > 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 Yes perhaps is better in the TDrawBuffer, I must check the code at home. But only as an "overkill", I think nobody must blindly write strings of any length. > > 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. Ok. > 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 did similar modifications to the sources of the editor, I just did a grep searching for const declarations (180 files ;-). > > 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) By now I'm just testing the version built here, if that's stable enough I'll patch some things and put it in the web. Testing with egcs+v2.02+bnu2.9 could be very interesting, but I think we must provide a version with gcc+v2.01+bnu2.8. Can you put your lastest patches in your web? Greetings, SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013