open, but some systems guarantee this even for non-setuid programs.
If an application is executed with fd 2 closed, use of @code{stderr}
can affect an unrelated file that happened to be assigned to fd 2.
-The gnulib *-safer modules may be used to guarantee that fd 2 stays
+The gnulib @code{xstdopen} or the *-safer modules may be used to
+guarantee that fd 2 stays
reserved for @code{stderr}.
@end itemize
open, but some systems guarantee this even for non-setuid programs.
If an application is executed with fd 0 closed, use of @code{stdin}
can affect an unrelated file that happened to be assigned to fd 0.
-The gnulib *-safer modules may be used to guarantee that fd 0 stays
+The gnulib @code{xstdopen} or the *-safer modules may be used to
+guarantee that fd 0 stays
reserved for @code{stdin}.
@end itemize
open, but some systems guarantee this even for non-setuid programs.
If an application is executed with fd 1 closed, use of @code{stdout}
can affect an unrelated file that happened to be assigned to fd 1.
-The gnulib *-safer modules may be used to guarantee that fd 1 stays
+The gnulib @code{xstdopen} or the *-safer modules may be used to
+guarantee that fd 1 stays
reserved for @code{stdout}.
@end itemize
@code{stdlib-safer}.
@end itemize
-The approach with the @code{xstdopen} module is simpler, but it adds three
+The approach with the @code{xstdopen} module is simple, but it adds three
system calls to program startup. Whereas the approach with the @code{*-safer}
-modules is more complex, but adds no overhead (no additional system calls)
+modules is more complicated and error-prone,
+and does not fix the problem if system library functions call one
+of the affected functions,
+but adds no overhead (no additional system calls)
in the normal case.
To use the approach with the @code{xstdopen} module: