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. Thanks! Collin
