Path: utzoo!attcan!uunet!munnari.oz.au!bruce!trlluna!rhea.trl.oz.au!aduncan
From: aduncan@rhea.trl.oz.au (Allan Duncan)
Newsgroups: comp.sys.amiga
Subject: Re: ZC 1.01 Problems
Message-ID: <1792@trlluna.trl.oz>
Date: 13 Jun 90 22:25:39 GMT
References: <20742@snow-white.udel.EDU>
Sender: root@trlluna.trl.oz
Lines: 29

From article <20742@snow-white.udel.EDU>, by GWO110%URIACC.BITNET@brownvm.brown.edu (F. Michael Theilig):
> 
>      I reciently grabbed ZC off of FF314 and set it up.  Everything got
>  set up properly and I created executable properly, but there is one
>  annoying side effect.  It seems that ZC won't print out any text until
>  a charage return is printed, i.e. when I do a printf with no ending
>  n, I don't see the text until one is printed.
> 
>      Is there any way around this?  Also, it seemed that parameters are
>  not being taken wrong.  I define argv as *argv[], rather than **argv.
>  I haven't looked into that problem thoroughly yet.  Anyone else find
>  any problems?
> 

No, this isn't a ZC bug, the behaviour is the same for most printf's.

The reason is that to get maximum speed for console output, the buffer
used is (say) 512 bytes, but it will be flushed when it it gets a \n, or
there is a call to stdin.  If you want it to be flushed earlier, tell it
explicitly with  fflush(stdio).
Alternatively, if you have the library sources, you can create a
one-byte buffer case for stdio if the stream "isatty".  I don't know
what the ZC library is like, but the relevant routine is probably
something like "getbuffer".

Allan Duncan	ACSnet	a.duncan@trl.oz
		ARPA	a.duncan%trl.oz.au@uunet.uu.net
		UUCP	{uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan
Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.