Re: Fwd: gnulib posix_spawn_file_actions_addclose

[Valery Ushakov]

On Wed, Sep 07, 2022 at 19:29:11 +0200, Bruno Haible wrote:

> > The addclose configure test succeeds b/c of this commit:
> > 
> >   
> > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=36a838b081de0d2c62970df5b4b8d736d3aebe1d
> > 
> > that makes configure test a negative fd instead of a large fd.
> 
> Yes.
> 
> > However tests/test-posix_spawn_file_actions_addclose.c still tests for
> > a large fd too and fails that test.
> 
> Yes. I believe the test verifies one of the assertions by POSIX [1].
> 
> > I wonder if either test-posix_spawn_file_actions_addclose.c should not
> > check for the "big" fd (and neither should spawn_faction_addclose.c
> > too?)  or the configure check should be reverted to check for the
> > "big" fd to make the two match.
> 
> I believe it's a POSIX compliance bug in musl libc, but Rich Felker
> disagrees. [2][3][4]
> 
> [1] 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_actions_addclose.html
> [2] https://www.openwall.com/lists/musl/2019/03/24/2
> [3] https://www.openwall.com/lists/musl/2019/03/24/5
> [4] https://www.openwall.com/lists/musl/2019/03/24/7

I can see that line of reasoning for the addopen case, though I would
need to read and think a bit more to make an informed comment.

However for the addclose case the [1] says in the ERRORS section:

  The posix_spawn_file_actions_addopen() function shall fail if:

  [EBADF]
      The value specified by fildes is negative or greater than or
      equal to {OPEN_MAX}.

  The posix_spawn_file_actions_addclose() function shall fail if:

  [EBADF]
      The value specified by fildes is negative. 


So I read it that the OPEN_MAX limit is - by explicit omission if you
excuse the oxymoron - not required for addclose (and that commit even
added the comment to that effect to the actual test).

That also seems to make sense.  In a real program the fd you pass to
addclose is some actual fd you obtained previously, so it must be
valid by construction.  If the fd is invalid *already*, in whichever
way, the child process will not be affected, b/c in any case it will
not have that fd open when it runs.  So even EBADF for negative
numbers is kinda redundant.


Anyway, my actual point is that the configure test and the actual test
in the tests subdir are not consistent.  I don't have any strong
preference for which way that inconsistency is resolved (though I do
lean towards the "negative only" side), but I think it would be nice
to resolve it one way or the other.

Thanks.

-uwe