Paul Eggert <[EMAIL PROTECTED]> wrote:
>>> And wouldn't there be an easier workaround: At the beginning of main(),
>>> use fcntl() to determine whether 0,1,2 are closed, and if so, replace
>>> them with open("/dev/null") ?
>>
>> Possibly. And if we did, it would make more sense to open fd 0 as write
>> only and fd 1 as read only, to be more likely to catch attempts to use
>> these streams when the user intended them to be closed.
>
> Jim did that in coreutils/lib/stdopen.c, I think with the idea of
> migrating it into gnulib if there was demand.
Right.
> Hmm, but this code
> currently isn't being used in coreutils. I don't offhand recall why.
It's not needed, now, afaik.
> Here's what I do recall. I swept coreutils for the sort of problem
> that stdopen would cure and fixed then with stdio-safer etc. Jim
> wrote stdopen.c in response, since this would be simpler than all
> those painstaking sweeps.
>
> If I missed nothing in my sweeps (an unlikely prospect!), then
> invoking stdopen merely adds a small amount of bloat to coreutils, and
> is unnecessary. A more-important argument against stdopen is that
> weird invocations like "cat /dev/fd/2 2>&-" would do the wrong thing.
In general, I think it's slightly better from a maintenance standpoint to
use stdopen.c than to make your code use the *-safer modules. The latter
requires constant vigilance, or, better, some automation to guard against
additions of unsafe functions. On the efficiency front, it's a trade-off.
stdopen.c comes with a small but constant overhead, while using the
*_safer functions, you incur the overhead of per-function-call wrappers.
And of course, stdopen.c is not an option in a library context.
