Turbo C++ 3.0 bugs

[Sean 'Captain Napalm' Conner]

It was thus said that the Great Chuck Guzis once stated:
> 
> On 12/14/2005 at 2:45 PM 9000 VAX wrote:
> 
> >
> >No, The order is not important. But I have a clue now. It might be
> >that Watcom C treats printf() function differently from other
> >functions. I think the compiler tends to delay the execution of
> >printf(), given that variables to be printed have not yet updated by
> >the program. But this trick (to execute printf() with other printf()'s
> >for speed?) does not work well if the program needs to read hardware
> >inside of printf(). I actually observed the "delayed printf()"
> >phenomenon and its effect here is my guess.
> 
> Well, printf() does write to a buffered stream, doesn't it, so it will be
> delayed unless you also issue a fflush(stdout) immediately thereafter.

  Or you call setvbuf().  You can turn off buffering on stdout by:

		setvbuf(stdout,NULL,_IONBF,0);

  But I'll stop here before turning this into a C support list 8-)

  -spc (Who ended up writing my own IO routines in C anyway ... )