While trying to use this crate inside a threadpool to do automated analysis of many binaries at once, I loaded down my system and had some spurious errors reported from 1) segmentation faults in the radare2 process itself due to uninitialized data and 2) a race condition where the managing process was trying to read the initial NULL byte from the subprocess and the subprocess hadn't initialized enough to a point to bind to the pipe. In both cases, r2pipe simply returned an error of "unexpected EOF" and, at least in the 2nd case, it was truly a case where r2pipe could have retried and succeeded instead of aborting the spawn completely. In the 1st case, I wound up manually hacking the r2pipe crate to figure out that the radare2 process was segfaulting, so I felt it was worthwhile reporting the exit status back in those cases so that end users can at least check on that case and decide what to do.
Additionally, I did a couple of cleanups in the first two commits to make it easier to make the latter two commits.
While trying to use this crate inside a threadpool to do automated analysis of many binaries at once, I loaded down my system and had some spurious errors reported from 1) segmentation faults in the radare2 process itself due to uninitialized data and 2) a race condition where the managing process was trying to read the initial NULL byte from the subprocess and the subprocess hadn't initialized enough to a point to bind to the pipe. In both cases, r2pipe simply returned an error of "unexpected EOF" and, at least in the 2nd case, it was truly a case where r2pipe could have retried and succeeded instead of aborting the spawn completely. In the 1st case, I wound up manually hacking the r2pipe crate to figure out that the radare2 process was segfaulting, so I felt it was worthwhile reporting the exit status back in those cases so that end users can at least check on that case and decide what to do.
Additionally, I did a couple of cleanups in the first two commits to make it easier to make the latter two commits.