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.