<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 12:03 AM Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Could you please submit a patch with this modification to the bugtracker ?<br>
<br>
We don't as a rule follow up on such things in github.<br></blockquote><div><br></div><div>I will of course submit a patch once I'm satisfied it is good enough.  My concern with the current patch is that a low level flush is called after every write statement, so a simple loop like the following:</div><div><br></div><div>for c := 'A' to 'Z" do write(c);</div><div><br></div><div>will incur the burden of a low level flush after each iteration.  In normal use the low level flush call is not needed and causes unnecessary blocks.  This is what Tomas mentioned, so I'm looking for a different implementation that can fit in with the rest of the use cases in the RTL.</div><div><br></div><div>It would make more sense to me if there was a distinct difference in use case between InOutFunc and FlushFunc (for fmoutput case), to my naive view it seems as if they are mostly used interchangeably and in many cases even share the same implementation function.  This makes sense for the traditional targets (Windows, Linux etc.), but for lower level targets a distinction between the internal RTL buffer and the external OS/hardware buffer is useful. For a low level target I would think an InOutfunc that flushes the internal buffer to the OS/hardware and a FlushFunc that ensures the internal buffer is empty and then blocks until the OS/hardware has completed transmission would make sense.<br></div></div></div>