Path: utzoo!attcan!uunet!mcvax!enea!tope
From: tope@enea.se (Tommy Petersson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Lattice C 4.0 bugs
Message-ID: <3889@enea.se>
Date: 16 Aug 88 15:52:37 GMT
References: <6627@bloom-beacon.MIT.EDU> <446@jc3b21.UUCP>
Reply-To: tope@enea.se (Tommy Petersson)
Organization: ENEA DATA AB, Sweden
Lines: 25
UUCP-Path: uunet!enea!tope

In article <446@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes:
>In article <6627@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes:
>>   puts("Enter any number to continue:\n");
>>   scanf("%d",&i);
>
>I believe puts() simply writes characters to a buffer.  It may be
>implemented as a macro.  Consequently, whey you use puts() for a short
>prompt string you don't see anything until the buffer is flushed.  The
>reason you see it when you press  is that your program terminates and
>all the buffers are flushed.  If you want to flush the buffers before that
>try flushall() or fflush() (described on page F-62).

(void) fflush (stdout) should work, but as observed it works anyway
on a lot of computer systems. Normally a read from stdin flushes
stdout first. Since the standard library is not a part of the C
language, it's implementation dependent.

This is just what I think, haven't started Amiga programming yet. (just
VAX-es and VAX-es...). A lot of C systems (I think Lightspeed C on
Mac, for one) includes the source for the standard library. Maybe
something could be "stolen" from there.

On a lot of systems the buffering or direct screen output is settable
on a system level, the C or Fortran or Pascal program all calls the
same system routine. The programmer doesn't notice this, it just works.