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 pressis 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.