Turbo C++ 3.0 bugs

[Sean 'Captain Napalm' Conner]

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
written).  

> 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 ... )