On Wed, Oct 29, 2025, 21:43 Collin Funk <[email protected]> wrote:
>
> Collin Funk <[email protected]> writes:
>
> > In fact, I think that glibc's behavior may violate POSIX requirements:
> >
> > It shall not be considered an error for the fildes argument passed
> > to these functions to specify a file descriptor for which the
> > specified operation could not be performed at the time of the call.
> > Any such error shall be detected when the associated file actions
> > object is later used during a posix_spawn() or posix_spawnp()
> > operation.
> >
> > One might have code that does the following:
> >
> > posix_spawn
> > posix_spawn_file_actions_t actions;
> > int result;
> > if ((result = posix_spawn_file_actions_init (&actions))
> > || (result = posix_spawn_file_actions_addclose (&actions,
> > getdtablesize ())))
> > error (EXIT_FAILURE, result, _("failed to setup posix_spawn"));
> > struct rlimit fdlimit = { .rlim_cur = getdtablesize () + 1,
> > .rlim_max = getdtablesize () + 1 };
> > if (setrlimit (RLIMIT_NOFILE, &fdlimit) < 0)
> > error (EXIT_FAILURE, errno,
> > _("failed to increase file descriptor limit"));
> > int result = posix_spawnp (...);
> >
> > Strange ordering, in my opinion, but POSIX wants the
> > posix_spawn_file_actions_addclose() to succeed since after the setrlimit
> > the close may be valid depending on whether the file descriptor gets
> > opened somewhere in else in the program.
>
> Hi Bruno, any thoughts on this? I'm considering opening a glibc bug
> report for it. But it would be nice to get another interpretation,
> whether or not it agrees with mine.
FWIW, Austin Group Defect 418 [1] seems directly on point and in line with
your interpretation.
[1] posix_spawn_file_actions_addclose() should not check against OPEN_MAX
https://austingroupbugs.net/view.php?id=418
