23 Dec
2017
23 Dec
'17
5:48 a.m.
Hello Team TUHS:
This note confirms that Random832’s System V Release 1 fix for CPIO and TAR core dump
works PERFECTLY!!!
iop->_cnt=0;
Truly,
Bill Corcoran
On Dec 22, 2017, at 4:09 AM, Random832 <random832(a)fastmail.com> wrote:
On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote:
Could the issue be with fprintf or doprnt.c?
I thought STDERR was unbuffered? Please forgive me.
I've got it. The problem is with putc (actually _flsbuf), and it is precisely
*because* stderr is unbuffered.
#define putc(x, p) (--(p)->_cnt >= 0 ? \
((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
_flsbuf((unsigned char) (x), (p)))
Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0,
and therefore every character is passed through _flsbuf.
However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting
this to zero (and does in other versions, both earlier and later), but we can see in
flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to
+32767, and putc now thinks the stream is buffered.
You'll want to add iop->cnt = 0 to the second if clause in _flsbuf.