Generate() and SpawnProcess() call fork(2) but did not check if it failed (return -1) and continued execution with possible unexpected results.
Handle fork(2) failure by throwing an exception.
Generate() and SpawnProcess() call fork(2) but did not check if it failed (return -1) and continued execution with possible unexpected results.
Handle fork(2) failure by throwing an exception.
Generate() and SpawnProcess() call fork(2) but did not check if it
failed (return -1) and continued execution with possible unexpected
results.
Handle fork(2) failure by throwing an exception.
84 | @@ -83,6 +85,9 @@ int SpawnProcess(int& pid, FdToArgsFn&& fd_to_args) 85 | } 86 | 87 | pid = fork(); 88 | + if (pid == -1) { 89 | + throw std::system_error(errno, std::system_category(), "fork");
Interesting, I didn't know system_error took a third string argument. It'd be good to start using this more places.
Yes, it also occurred to me that if std::system_category() modifies errno then std::system_error() may get the wrong value of errno:
#include <errno.h>
#include <stdio.h>
int f1() {
errno = 3;
return 20;
}
void f2(int e, int x) {
printf("%d %d\n", e, x);
}
int main(int, char**) {
errno = 2; // resulted from fork() or whatever
f2(errno, f1());
return 0;
}
produces:
# clang 9.0.1
$ clang++90 t.cc -o t && ./t
2 20
# gcc 9.2.0
$ g++9 t.cc -o t && ./t
3 20
It's a possible concern, but in practice if that constructor was setting errno, it would probably break a lot of things. Also in the worst case error message text would just be less clear
Yes, safe to ignore in this case. Just the pattern func1(x, func2_may_possibly_modify_x()); is better to be avoided.
system_error took a third string argument. It'd be good to start using this more places.
https://github.com/chaincodelabs/libmultiprocess/pull/23 Tell std::system_error() which function failed
Cheerz!
Tested ACK 16ebae8225ce3bf91ac0217704c12b67e5c81109. Thanks for catching this, and also fixing more missing includes