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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk