Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert <eggert@cs.ucla.edu>]

On 11/13/2017 06:13 AM, Matthias Dahl wrote:
>> This is overkill, as the total amount of bytes read by a call to
>> read_process_output cannot exceed 4096, so all we need is an unsigned
>> counter with more than 12 bits. How about making it 'unsigned int'
>> instead? It could even be 'unsigned short', though that might be
>> overkill. Whatever size is chosen, the comment should say that the value
>> recorded is the true value modulo the word size.
> That would not be enough. The counter is for the entire process lifetime
> and not just for a single read back or chain of recursive read backs.

It cannot be for the entire process lifetime, since it's an unsigned 
integer that is designed to wrap around on overflow. So it sounds like 
you want a counter modulo 2**N for the entire process lifetime, and 
we're discussing what value of N is large enough for the purposes of 
wait_reading_process_output. Since EMACS_UINT might be only 32 bits, and 
it's eminently reasonable for a process to read more than 2**32 bytes 
during its lifetime, this is not a theoretical issue.

So: why must the counter contain more than a small number of bits (16, 
say)? I'm not seeing the scenario. I'm asking not because I think it's 
important to save a few bits in the counter: I'm asking because I want 
to understand the change and the reasoning behind it, so that I can be 
sure it's fixing the bug.