TurboC Bugs and Issues

Porting Borland Turbo C source code to GNU gcc

 Home  Usage  Download  Change log Bug list
"Sister Talk" by Lynn Rothan
    Warning:  By its very nature, TurboC is not a project with a lot of range for improvement.  Like Popeye the Sailor, it is what it is, and that's all that it is.
    Nevertheless, if I discover bugs or other issues, or if I'm informed of them, I'll record them here for posterity.  I may or may not fix them.
    See also the function list , where limitations of various library functions are discussed.

    Download the latest development snapshot here.

Number Type Description Status
02/17/04:  Jim Huang has reported that in some (unspecified) version of *nix, the textmode.c file does not compile, because of incompatibilities between the ACS_xxx macros and the integer-type reassignments.  This affects only systems on which the library has never been compiled, and therefore is of no value to anybody already using the library.
Fixed in versions 02/18/04 and later.
02/12/04:  The hex2h.c file, which is actually a utility program, gets put into the libraries (in the form of a main function).  Thanks to Jozeph Brasil for pointing this out.  It doesn't seem to affect most users, but sometimes causes a multiply-defined function warning during compilation.
Fixed in versions 02/14/04 and later. 
11/01/03:  In trying to compile under SuSE 8.2, I find that there have been changes in the standard headers that cause a conflict between TurboC's gettext and the libintl's gettext.
Fixed in versions 11/02/03 and later.  There is now a gettextIntl function which encapsulates libintl's function.
12/16/02:  Johnny Piette has reported various problems with compiling TurboC under gcc 3.x and/or newer system library versions:  getdate and fcloseall prototypes conflict; also, linking the Test.cpp test program gives a "missing __gxx_personality_v0" error.
Fixed.  Note:  In general, it seems as though with gcc 3.x, it may be necessary under some circumstances to compile c++ programs with the compiler actually called "c++" rather than with "cc" or "gcc".
36 Bug 06/02/02:  The diagonal line in the 3rd graphics screen of the GraphicsTest test program does not appear in FreeBSD. To-do.
35 Bug 06/02/02:  The method of directly accessing an ncurses _line structure directly in gettext and puttext is not portable.  This causes TurboC to not compile in SuSE 8.0. Fixed.
34 Bug 05/25/02:  In graphics mode, getch returns regular keystrokes, but not special keys like arrows, F1-F10, etc. To do.
33 Bug 05/22/02:  In fillpoly, the foreground color of the border line is not correct.  (It acts as though the foreground is transparent.)

05/25/02:  Same thing, but for the sector function.

To do.
32 Issue 05/21/02:  Handling the situation in which the user manually closes the text or graphics window needs to be handled more gracefully.  Manually closing the graphics window is now prevented (good!), but I can't remove the X button in the corner of the window.  The text window, on the other hand, can be manually closed, and I don't know how  to prevent it or to insure a graceful shutdown. Look into it.
31 Bug 05/07/02:  getch and getche work only in textmode.  Similarly, getchar works only when not in textmode.  If graphics modes is used, getchar and getch don't work unless the focus is on the xterm window rather than the graphics window. To do. 

Partial fix 05/09/02:  getch now works from a graphic window, whether or not it has been initialized with textmode.

30 Issue The fcloseall function seemingly does not exist in FreeBSD. Hmmm ...
29 Bug When running remotely, found some escape-key sequences I hadn't found before for F1-F5, F10, so that these keys wouldn't register.  This seemed consistent across platforms when running ssh. 04/20/02, fixed.
28 Bug Still a residual timing problem with the initial screen resizing, when running remotely. 04/20/02, hopefully fixed by lengthening the timing loop for the screen resizing.
27 Issue Probably never worked properly in a FreeBSD xterm.  (I had only run it remotely, and never locally on a FreeBSD box.) This is simply a question of using the proper settings with xterm , which requires the command switch "-tn linux" to match the environment I've actually been developing in.
26 Bug No longer compiles under FreeBSD. Fixed 04/20/02.
25 Bug If the user manually resizes the xterm console, and the TurboC library subsequently restores the original size, portions of the screen may not be automatically redrawn. Fixed 04/20/02, I think.
24 Bug Found that strcpy (and presumably strncpy) may be implemented as macros and may therefore suffer from the bug reported as PR #22. Fixed 04/18/02.
23 Bug The the user physically resizes the console to be too small, subsequenct calls to ConioResizeCallback will not occur.  This may have something to do with an error return in resizeterm. To do.  However, as of 04/18/02, the default behavior on resizing the terminal is to restore it to the size specified in textmode, and hence ConioResizeCallback would no longer be used anyway.
22 Bug For some reason, when integer datatype conversion is turned on, you have to compile the code you're porting with optimization level -O0.  If you use an higher level (such as -O1), some fairly inexplicable compiler errors occur. Fixed 03/24/02.  At least, strcmp, strncmp, strcmpi, stricmp, and strncmpi are fixed.  There may be others I haven't detected yet.  The problem is apparently the potential implementation of some functions a macros that may contain casts like (unsigned char *).   I don't know why this would have worked at -O0, but apparently it did. 
21 Bug Apparently, adding the special display characters (like linedraw characters) broke tabs. Fixed 03/24/02.
20 Bug In movetext and puttext, if current window is not the full-screen, it may not be updated properly after the operation. Fixed 03/23/02.
19 Bug The libTurboC cgets function incorrectly performs a carriage return on receiving a carriage return input character. Fixed 03/21/02.
18 Bug The libTurboC cgets function returns non-nul-terminated strings. Fixed 03/21/02.
17 Bug cgets conforms to the documented behavior, in aborting after reaching the specified maximum number of characters.  However, actual Turbo C does not behave this way; its cgets cannot terminate until a carriage return occurs. Fixed 03/21/02.
16 Issue Linking TurboC library to C++ code fails with many functions not found.  Thanks to Peter Carroll for bringing this to my attention.

Explanation:  I was targeting only Turbo C 2.x, and failed to realize that people with Borland C++ 3.x or 4.x might be using C++ rather than C.  The TurboC header files don't yet have the extra goo needed for C++ compatibility.

Fixed 03/18/02.
15 Bug The Makefile will fail to build Test and TurboCChars (but will correctly build libTurboC.a) prior to placing the header files in with the system headers. Fixed 03/18/02.
14 Serious bug Apparently, my entire notion of using ncurse windows to emulate Turbo C windows is bogus, because ncurses windows are like sprites:  they stand in front of the windows behind them, but don't modify those windows.  Hence, when they are closed, their contents disappear completely. Fixed 03/17/02.
13 Bug In the following code,
  cprintf ("xxx %c yyy", 0);
actual Turbo C displays the entire string, whereas the %cterminates the TurboC library cprintf after "xxx " because it effectively inserts a nul into the string.   Only the character substitution value of 0 is affected.
It's very unlikely I'll ever fix this.  Change it manually in your code.
12 Issue There's a several-second delay upon starting the ported program.  Explanation:  This delay occurs if the ported program is not being run under xterm; the delay is due to attempting to resize the xterm console to the proper number of lines and columns. Fixed 04/18/02.
11 Bug All unshifted characters on the numeric keypad may not work:  0-9, enter, '.', '+', '-', '*', '/', '='. Fixed 03/16/02.
10 Issue If the user physically resizes the console to smaller than the logical size of the console, a segfault can occur. Probably fixed 03/31/02.  For this fix to be effective, it's best to run the ported program under xterm.
9a Issue It is not possible to prevent the user from physically resizing the console to an inappropriate size. I don't believe it's possible to completely fix this if ncurses is used, but as of 04/18/02, the terminal is automatically restored to its correct size after a user manually resizes it.  For this fix to be effective, the ported program should be run under xterm.
9 Issue The textmode function cannot physically resize the console. Partially fixed 03/16/02.  If xterm is used, the console is physically resized.  If not (for example, if KDE Konsole is used instead, or if an actual hardware text mode is used instead of the X-window system), the problem persists.  I'm happy to call this problem "resolved", and simply require that xterm be used for full functionality, but others may not be.
8 Conceptual* It's not possible with ncurses to mimic all Borland conio keystrokes (like Ctrl-Alt-F1).  Furthermore, even the keystrokes that can be mimicked depend on how the *nix console being used has been initialized.    Different console programs and different initializations for those programs may produce different numerical codes for the keystrokes. I don't think anything can be done about this within TurboC itself.  A utility program is provided (CheckKeystrokes) with which you can check what special keys are working.  You'll simply have to change your source program accordingly.

03/16/02:  Support for special keys has now been greatly enhanced, to the point where it probably can't be improved much.

7 Bug The clrtoeol function, if the console is wider than the screensize as defined with the textmode function, clears to the physical edge of the console. To do.  However, since the physical terminal width matches the logical terminal width (as of 04/18/02) when the ported program is run under xterm, I am liable to think of this problem as being resolved.
6 Conceptual* Filenames hardcoded into a program will likely not work, because of things like drive-letters ("c:"), backslashes rather than forward slashes, and case-sensitivity. Unfixable within TurboC.  Please fix manually.
5 Conceptual* The TurboC header files redefine the int, short, unsigned, and long datatypes.   For this reason, they must follow standard header files such as stdlib.h and stdio.h. Unfixable within TurboC.  Please manually reorder the header-file inclusions within your source files.  Current TurboC header files are conio.h and alloc.h.
4 Conceptual* Borland Turbo C runs on an 'x86 CPU, which is a "little endian" processor.  Byte ordering will be different on "bit endian" processors such as PowerPC.  In most cases this won't matter at all, but it may affect file read/writes to files of specified formats. Unfixable within TurboC.  Please fix manually.

Note:  Various endian-conversion functions have now been provided, but they must be manually inserted into the code.

3 Issue Various Turbo C library functions are missing from TurboC. I know it.  Tell me specifically what functions you need, or (better yet) write them and send them to me.
2 Conceptual* Various integer datatypes differ between Turbo C and GNU gcc .  Some can be converted automatically by TurboC; some cannot.  Refer to the summary table. Unfixable within TurboC.  Please fix manually.
1 Conceptual* Structure sizes and field packing may not be (probably aren't) the same as in Turbo C.  This can affects file reads/writes using complete structures or arrays of structures as file-records. Unfixable within TurboC.  Please fix manually.
*In other words, a problem in the very concept of TurboC, and not fixable within TurboC.  A custom pre-processor program would be required, and it's not worth the effort to provide anything like that.

©2002,2004 Ronald S. Burkey.  Contact me.