Mail Archives: djgpp/1997/08/17/03:45:41
In article <33F0D3EA DOT 528A AT cs DOT com> fighteer AT cs DOT com "John M. Aldrich" writes:
>Lawrence Kirby wrote:
>>
>> 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 suppose that "fully buffered" is defined somewhere as well, or we'll
>be chasing each other in circles over its proper meaning. However,
>stdout in DJGPP is line buffered by default, which AFAIK conforms with
>ANSI requirements.
If that is the case then yes it does. However this thread was started
by an article containing the following extract:
>>I have been messing around with Borland C for a while. I wanted to try
>>that free 32 bit compiler DJGPP. I finally figured out what I had to
>>download. I also got RHIDE, the free IDE. So, I wrote my first little
>>C in the new compiler.
>>
>>#include <stdio.h>
>>#include <conio.h>
>>#include <dos.h>
>>
>>main()
>>{
>>clrscr();
>>printf("Hello there\n");
>>getch();
>>printf("See You Later!");
>>delay(1000);
>>}
>>
>>And here is the funny thing. This program wrote nothing until I hit a
>>key. It was Obviously supposed to write "Hello there" first.
....
which suggests that stdout is fully buffered by default.
>There is a good reason for this; the overhead of the
>mode switches required to send text to the DOS file handling functions
>is high enough to make line buffering a good tradeoff for speed. It's
>really simple to work around or disable it, though.
You get no arguments here!
>But the major thing that you've overlooked is that conio and stdio
>functions were not meant to be mixed. stdio reads and writes data to
>the DOS file handling routines, while conio reads directly from the BIOS
>keyboard and writes to text video memory. The two are mutually
>incompatible; it's merely coincidence that they work together on some
>compilers.
So you are saying that the clrscr() prevented the "Hello there\n" being
output immediately? Of course as far as the C language is concerned that
is perfectly valid (anything that happens after then non-standard header
<conio.h> is included is valid). However it is surprising. Mabe it is
just a lesson not to try to guess at platform-specific behaviour! :-)
>One of the features of the stdout buffering in DJGPP is that if you call
>an input function that reads from stdin, the buffer is automatically
>flushed. The following works perfectly, although it requires a carriage
>return after the character is typed:
>
> printf( "Type a character: " );
> getchar();
>
>The advantage to conio functions is that you really can read a single
>character at a time. But if you use conio input routines, you ought to
>use conio output routines as well. The following also works without
>fiddling with buffers:
>
> cprintf( "Type a character: " );
> getch();
That may well be good advice but does it really explain what is going on
here? A simple test for the original poster would be to see what this
does:
#include <stdio.h>
int main(void)
{
printf("Hello there\n");
for (;;)
;
}
--
-----------------------------------------
Lawrence Kirby | fred AT genesis DOT demon DOT co DOT uk
Wilts, England | 70734 DOT 126 AT compuserve DOT com
-----------------------------------------
- Raw text -