Re: purpose of *-safer?

[Jim Meyering]

Paul Eggert <address@hidden> 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.