|Anonymous | Login||2020-07-06 08:59 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001341||[1003.1(2016)/Issue7+TC2] System Interfaces||Objection||Error||2020-05-05 04:53||2020-05-07 14:02|
|Page Number||1452 ff.|
|Line Number||48227 ff.|
|Final Accepted Text|
|Summary||0001341: The resolution of 0001208 as amended by Note: 0004830 is incorrect|
Issue 0001208 was reopened (just yesterday) but has been closed to
new notes (already!) or I would have simply appended this there.
The change to the resolution made bu Note: 0004830 is wrong, the text was
correct before. posix_spawn() is intended to be implemented as a system
call (or at least be able to be implemented that way) - it cannot do PATH
searches to locate utilities - the PATH search needs to have been done
before calling posix_spawn() (my own comments in Note: 0004851 to 0001340
notwithstanding - I wasn't thinking when I wrote those either).
The text proposed before Note: 0004830 was added appears better.
|Desired Action||Delete Note: 0004830 and return to the previous resolution of 0001208|
|Tags||No tags attached.|
The text being amended by Note: 0004830 is about posix_spawnp(), not posix_spawn(). The existing text states that a PATH search is done; the change is just to clarify how that search is done now that there is a "chdir" file action.
Robert, please consider asking for this bug to be withdrawn. (It can then be closed straight away, instead of taking up time in a teleconference to process it as rejected.)
edited on: 2020-05-05 17:36
You're right, I missed the 'p' in the function name in Note: 0004830
so if you want to just close this bug report (which is clearly not
appropriate as it is) then please go ahead.
But before you do, could someone tell me if there is actually an
implementation of posix_spawnp() that actually processes the
chdir option to the eventual posix_spawn in the way it is intended here?
I can see that it would be possible (though rather messy and ugly) to
handle the posix_spawn_file_actions_addchdir( ) type chdir call, as that
just requires a whole bunch of string manipulation to the paths as they're
being constructed from PATH and the arg while we build the pathname to
hand to an eventual call of posix_spawn().
But handling posix_spawn_file_actions_addfchdir( ) in posix_spawnp() in
general looks impossible to me - the only correct way to do it is to
actually change directories (do a fchdir()) (since there is no guarantee
that the directory referenced by the fd actually has a name by which it
can be referenced, hence there is no guaranteed way to use any kind of
string manipulation to produce paths that work from $PWD to reach sub-dirs
of the directory whose fd is to be used by posix_spawn() for the internal
fchdir. And that we cannot safely do.
So, while my earlier reasoning is clearly nonsense, I still believe that
the change in Note: 0004830 is wrong - but now what I suggest is to instead
Use of the posix_spawn_file_actions_addfchdir() [and probably
posix_spawn_file_actions_addchdir() as well] with the posix_spawnp()
function produces unspecified results.
after which the current intended change (Note: 0004830) is clearly not required.
Certainly unless there is an actual implementation of posix_spawnp()
which processes each of those options in a sane way, this should be the
only possible action - we cannot invent new interfaces and specify how
they're required to work without at least some working (and sane - ie:
working in a rational way) implementation to verify that it is indeed possible.
Re Note: 0004858
The new specified behaviour is what naturally happens if posix_spawn() and posix_spawnp() are implemented using fork and exec, as in the XRAT B.3.3 example implementation of posix_spawn() as amended by bug 1208. (This can be turned into a posix_spawnp() implementation by doing a PATH loop around the execve() call, if path does not contain any slashes.)
An implementation that chooses to make posix_spawn() a system call needs to ensure the end result is the same as for a typical fork+exec implementation. On such a system, presumably posix_spawnp() would be a C library function that calls a posix_spawnp system call passing it the value of PATH as an extra argument.
edited on: 2020-05-07 08:19
Re Note: 0004858 "could someone tell me if there is actually an implementation of posix_spawnp() that actually processes the chdir option [...] in the way it is intended here?"
Casper Dik reported on the mailing list:
The Solaris posix_spawnp() system call implementation does has an action to change chdir and it will actually search the PATH in the kernel.
|OK, please close this bug...|
|2020-05-05 04:53||kre||New Issue|
|2020-05-05 04:53||kre||Name||=> Robert Elz|
|2020-05-05 04:53||kre||Section||=> posix_spawn|
|2020-05-05 04:53||kre||Page Number||=> 1452 ff.|
|2020-05-05 04:53||kre||Line Number||=> 48227 ff.|
|2020-05-05 05:07||kre||Note Added: 0004852|
|2020-05-05 05:09||kre||Note Deleted: 0004852|
|2020-05-05 08:18||geoffclare||Note Added: 0004853|
|2020-05-05 15:28||kre||Note Added: 0004858|
|2020-05-05 15:30||kre||Note Edited: 0004858|
|2020-05-05 17:36||kre||Note Edited: 0004858|
|2020-05-06 08:47||geoffclare||Note Added: 0004865|
|2020-05-07 08:18||geoffclare||Note Added: 0004867|
|2020-05-07 08:19||geoffclare||Note Edited: 0004867|
|2020-05-07 10:56||kre||Note Added: 0004870|
|2020-05-07 14:02||geoffclare||Interp Status||=> ---|
|2020-05-07 14:02||geoffclare||Status||New => Closed|
|2020-05-07 14:02||geoffclare||Resolution||Open => Withdrawn|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|