Turbo C++ 3.0 bugs

[Sean 'Captain Napalm' Conner]

It was thus said that the Great mbbrutman-cctalk at brutman.com once stated:
> 
> Quoting Sean 'Captain Napalm' Conner <spc at conman.org>:
> 
> > 
> >   Which isn't vanilla C (but may be vanilla C++) ... 
> 
> Except for the function name, a C compiler would be pretty happy with it.  The
> compiler is bad, but not that bad!
> 
> >   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).  
> 
> I'm guessing this too, but I can't figure out the difference.  When the extra
> constant is not there a 0x0004 gets loaded into AX.  When the extra constant is
> there, a 0x0005 gets loaded into AX.  I might be looking at the wrong register
> before the call, but I never see a case of 0x0 or 0x1 being moved in - I think
> the 0x0004 and 0x0005 are the correct offsets.

  The problem may be happening at the linking stage, not the runtime stage
(although that's there the anomalous behavior is seen).  A sequence like:

	printf("%d %s",23,"hello");

Produces code like:

		segment	data

		text1	db	'%d %s',0
		text2	db	'hello',0

		segment	code

		pushl	offset text2
		pushl	23
		pushl	offset text1
		call	printf

But the object code produces an output like:

	data_blob
	
		text1:	db	'%d %s',0
		text2:	db	'hello',0

	code_blob

		line1:	pushl	0
		line2:	pushl	23
		line3:	pushl	0
		line4:	call	0

	fixup_data

		in code_blob @ line1 byte offset 1 change to address of
			data_blob line 2

		in code_blob @ line 3 byte offset 1 change to address of
			data_blob line 1

		in code_blob @ line4 byte offset 1 change to address of
			external_code_blob printf

  It may be that because the offset of text1 is at offset 0 of the data
segment (as stored in the data_blob) the linker may think it's actually NULL
and do something different.  It's not a compiler error, so running the
resulting code under a debugger won't find it---it's a linking error.

  -spc (has found compiler errors, but never a linker error ... )