mey@astbe.UUCP (Thomas Meyer) (12/13/88)
We are using Turbo C 2.0, its TLIB utility and the stand-alone debugger TD. Recently I discovered the following effect. I created a library containing modules, which were compiled with debug options. The manual states, that debugging of modules in libraries *is* possible, provided that - the modules were compiled with debug option set, - the library was *not* created with the "Create Extended Dictonary" option, - the source code of the modules is available and - the source code directory option in Turbo Debug is set appropriately. Though those conditions were fulfilled, the debugger refused to show the source code of libary functions. Worse, the programme crashed, when the the first function in the library was called. (The library is quite big, about 200K) Finally I resolved the problem by using the TLIB utility which came along with Turbo C 1.5, which does the job fine and allowes me to debug modules stored in libraries. Did anyone had similar experiences and can give an explanation ? Are there more known bugs ? Inspite of this time-consuming experience Turbo C 2.0, especially its stand-alone debugger, surpassed our expectations.
uh@materna.uucp (Uwe Hoch) (12/21/88)
In article <458@astbe.UUCP> mey@astbe.UUCP (Thomas Meyer) writes: > >Did anyone had similar experiences and can give an explanation ? >Are there more known bugs ? Yes, we found two bugs and one documentation fault in the german handbooks of TC 2.0. 1. If the pseudo-function "__emit__" should be used, the file "dos.h" MUST be included. Otherwise the compiler fails with a curios error message. This is NOT documented in the german handbooks. 2. In the following program the linker fails to include the format functions for scanf. #include <stdio.h> void y (float *R) { sscanf("1.24","%f",R); } void x (void *Data) { y((float *)Data); } void main (void) { float R; x(&R); } Question: Is this a compiler or a linker error??? The same program works fine with MS-C 5.1. 3. The function "intr" of the standard library works not always correct. The BP-Register is not set up with the value you put into the corresponding data structure. The error seems to be, that the wrong offset is computed to get BP from the stack (the last statment before the assembly "int" statment). I found the error in all model libraries with the Turbo Debugger (very good tool for debugging Turbo C :-) ). Also I have patched the libraries, so that the function now works fine. Unfortunately I have no sources of the library functions, so if someone has them, he can look for the error. The last two errors have been reported to Heimsoeth Software, the offical german distributor of Borland two or three weeks ago, but the guys have not sent any answer to me until now. Though I'm still a fan of all Borland products, especially of the new debugger. Uwe Hoch Dr. Materna GmbH Vosskuhle 38 D-4600 Dortmund 1 West Germany E-Mail: USENET: uh@materna.uucp ..!seismo!mcvax!unido!materna!uh