At 2005-01-12T11:33:32+1300, Volker Kuhlmann wrote:
> Thanks Matthew, I was wondering whether it had to do with descriptor
> inheritance. One could call it a bug in the process though, to call
> programs with insane descriptors. Nevertheless, what would be the
> correct way for testing in "program" whether the standard descriptors
> are sane?
Use fstat() (or your language's equivalent) to check the file
descriptors you care about (in increasing order), then reopen the as
approriate, e.g.:
if (fstat(STDERR_FILENO, &stat_buf) == -1)
if (open("/dev/null", O_WRONLY) == -1)
abort();
> (Minor: stderr is fd 2)
At 2005-01-12T13:00:18+1300, Carl Cerecke wrote:
> Presumably you're actually talking about fd 2 in steps 3 & 4.
Thanks, yeah, my brain experienced an off-by-one.
> This could be partly solved by the OS by never reusing file
> descriptors lower than 3.
It could be, but that's probably not the right solution. It's extremely
useful to be able to reopen stdin/stdout/stderr however you please, e.g.
easy logging to a file by writing any log output to stderr, then
reopening stderr as a log file, or think of what the shell does with ">
/dev/null". If open()-like calls were prohibited in the way that you
suggest, you'd need to create a new API for remapping
stdin/stdout/stderr.
> perror would then probably fail silently, but fprintf(2,xxx) (which
> I'm guessing perror uses) would correctly return -1.
glibc certainly uses a technique that can be approximated as fprintf(2,
...), and it doesn't check the return value of fprintf.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
