Re: [boost] [process] Formal Review

Subject: Re: [boost] [process] Formal Review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-11-06 21:38:45

On 6/11/2016 14:10, Klemens Morgenstern wrote:
>> The example under I/O pipes the stdout from 'nm' to the stdin of
>> 'c++filt'. But the example code seems completely unaware that c++filt
>> could be delayed for any of a number of reasons. It assumes that as
>> soon as nm terminates, c++filt must have produced all the output it
>> ever will. I worry about the Process implementation being confused
>> about such issues.
>
> I fear you are right, I'd need to be checking for an empty line at the end.

Once the pipe-closing issues are resolved, you should simply read the 
output stream until EOF.  This will only occur once c++filt has 
terminated (and thus completed and closed its output stream).

(This is the right thing to do regardless of whether it's sync or async.)

>> The documentation so consistently uses literal ';' as the PATH
>> separator that I worry the code won't correctly process standard Posix
>> PATH strings.
>
> I'll look into that.

A common tactic to resolve this sort of issue is to provide a 
platform-dependent property that contains the joining character and/or a 
join() method.  Of course, encouraging developers to actually *use* them 
instead of hard-coding it is another matter.

>> * On Windows, if you desire to pass any file handles at all to the new
>> child process, it is completely whimsical what *other* open file
>> handles you may inadvertently pass -- unless you play games with
>> STARTUPINFOEXA and PROC_THREAD_ATTRIBUTE_LIST to enumerate exactly the
>> set of handles you intend to pass.

FWIW, a slight saving grace with that is that it's most common to open 
files using NULL security attributes, which makes the file non-inherited 
by default.  You can also flip any existing handle to non-inherited 
whenever you want.