[TUHS] SYSTEM V R1 HELP

[wlc@jctaylor.com (William Corcoran)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

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