Gil,

I agree; that sounds like a defect (or enhancement? :-)



On Mon, Jul 15, 2013 at 10:38 AM, Paul Gilmartin <paulgboul...@aim.com>wrote:

> On Mon, 15 Jul 2013 09:23:40 -0500, Kirk Wolf wrote:
> >
> >Maybe that is one of the "enhancements" ? :-)
> >
> Exoskeletal "enhancement"?  Is there any rationale for making the
> ASCII behavior different from the EBCDIC?
>
> >Actually this seems to be an issue with the stream buffering strategy.
> >See the C/C++ RTL Ref for "setvbuf()".   Maybe you need to explicitly call
> >setvbuf() for stdout/stderr with __LIBASCII ??
> >
> In fact, "setvbuf( stdout, NULL, _IONBF, 4096 );" repairs the lazy
> buffering.
> Surprisingly, _IOLBF lacks that effect.  Feels like a bug?
>
> loc. cit.:
> _IOLBF
>     Line buffering is used for text stream I/O and terminal I/O. The
> buffer is
>     flushed when a newline character is used (text stream), when the buffer
>     is full, or when input is requested (terminal). The value for size
> must be
>     greater than 0.
>
> Hmmm.  On a hunch, I added "...\025" to the end of each format string.
> Now, the buffer gets flushed, even with _IOLBF.  Ah!  It's that kind of
> bug.
>
> Guess what I hate!
>
> Thanks,
> gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to