From: firewind Newsgroups: comp.lang.c,comp.os.msdos.djgpp Subject: Re: A funny thing happened! Date: 11 Aug 1997 22:36:03 GMT Organization: Netcom Lines: 42 Message-ID: <5so44j$2fn@sjx-ixn8.ix.netcom.com> References: <33EE4447 DOT 24E09407 AT nospam DOT net> <871305859snz AT genesis DOT demon DOT co DOT uk> NNTP-Posting-Host: elp-tx3-05.ix.netcom.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Lawrence Kirby wrote: > In article <33EE4447 DOT 24E09407 AT nospam DOT net> t AT nospam DOT net "Klaus Thane" writes: > >#include > >#include > >#include > > > >main() > >{ > >clrscr(); > >printf("Hello there\n"); > >fflush(stdout); > >getch(); > >printf("See You Later!"); > >delay(1000); > >} > Note that you've used lots of things that aren't defined by the C language > here (, , clrscr(), getch() and delay() ). > As to your question what you appear to be seeing is stdout fully buffered. > The standard says that stdout should be set by the implementation as > fully buffered if and only if it can determine that it doesn't refer to > an interactive device. It would be reasonable to say that your screen is > an interactive device so the compiler is in error making stdout fully > buffered. However it is left to the implementation to define what > "interactive device" means. So if DJGPP doesn't consider the screen to > be an interactive device it is within its rights. It is a case that DJGPP > might be violating the spirit of the standard but maybe not the letter. > I've cross-posed this reply to comp.os.msdos.djgpp in case there is any > comment there. The compiler is, in no way, in error. stdio functions write (correctly) to stdout, while conio functions use BIOS calls or directly touch the hardware (I forget which). The stdio functions are therefore unaware that input is being attempted, and so output is not flushed. However, outputting a newline -is- supposed to flush the buffer automagically. (BTW, this is dicussed very thouroughly (sp) in the FAQ.)