Turbo C++ 3.0 bugs
Sean 'Captain Napalm' Conner
spc at conman.org
Tue Dec 13 23:02:42 CST 2005
It was thus said that the Great Michael B. Brutman once stated:
> I remember when I first used this piece of low-budget software 12 years
> ago that it had some interesting bugs, most of which surfaced when you
> used 'clever' features of C++, such as pure virtuals, destructors, etc.
> I've been using it to do a small TCP/IP implementation for a PCjr and
> have been sticking to vanilla C. After a few weeks of coding I've hit a
> bug that has just bewildered me.
> Take the following code:
Which isn't vanilla C (but may be vanilla C++) ...
[ snip ]
> After a few hours of wrestling with this I am fairly sure it is a bug in
> the linker, and it has to do with the string constant on the sprintf.
> If it is the first string constant in the file, it doesn't work. If I
> do anything that adds another string constant before that one, it works,
> even if the other string constant is never referenced or used.
Sounds like a fixup problem. If it's the first constant string, then it
sounds like it's at offset 0 of some segment, and the linker may be thinking
it's a NULL value (easy to see how this could happen actually). And it may
be that that implementation of sprintf() checks for a NULL string, and if
so, "does the right thing" (not print anything, and return 0 characters
> Has anybody run into something similar to this? I'm using tdump
> (supplied with the compiler), the linker's map file, and debug to try to
> figure out the code gen and the suspected fixup error, but I can't see
> anything obviously wrong. Hints on tracking this would be appreciated.
Can you produce Microsoft .obj files and link with LINK.EXE?
-spc (Either that, or just forget C++ and use C ... )
More information about the cctech