Fix freopen() where the path is null.
This has been in the standard since C99, but we've never supported it
before. It's apparently used by SPIRV-Tools.
I tried implementing this the other way (with fcntl(2)) first, but
eventually realized that that's more complicated and gives worse
results. This implementation assumes that /proc is mounted, but so much
of libc relies on that at this point that I don't think there's any
realistic case where the fcntl(2) implementation would be preferable,
and there are many where it's not.
The fact that no-one's mentioned this until now suggests that it's not a
heavily used feature anyway.
I've also replaced AssertCloseOnExec() with a CloseOnExec()
boolean-valued function instead, because it's really annoying getting
assertion failures that don't point you at the test line in question,
and instead point to some common helper code.
Test: treehugger
Change-Id: Ia2e53bf2664a4f782581042054ecd492830e2aed
diff --git a/tests/utils.h b/tests/utils.h
index 94ff050..145ba1a 100644
--- a/tests/utils.h
+++ b/tests/utils.h
@@ -185,10 +185,14 @@
}
}
-static inline void AssertCloseOnExec(int fd, bool close_on_exec) {
+static inline bool CloseOnExec(int fd) {
int flags = fcntl(fd, F_GETFD);
- ASSERT_NE(flags, -1);
- ASSERT_EQ(close_on_exec ? FD_CLOEXEC : 0, flags & FD_CLOEXEC);
+ // This isn't ideal, but the alternatives are worse:
+ // * If we return void and use ASSERT_NE here, we get failures at utils.h:191
+ // rather than in the relevant test.
+ // * If we ignore failures of fcntl(), well, that's obviously a bad idea.
+ if (flags == -1) abort();
+ return flags & FD_CLOEXEC;
}
// The absolute path to the executable