posix_spawnp() and PATH - change code or manual ?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Our man page for posix_spawnp() says...

     The file parameter to posix_spawnp() is used to construct a pathname that
     identifies the new process image file.  If the file parameter contains a
     slash character, the file parameter is used as the pathname for the new
     process image file.  Otherwise, the path prefix for this file is obtained
     by a search of the directories passed as the environment variable "PATH".
     If this variable is not specified, the default path is set according to
     the _PATH_DEFPATH definition in <paths.h>, which is set to
     "/usr/bin:/bin".

The code in posix_spawnp() does ...

        if (strchr(file, '/') != NULL || (path = getenv("PATH")) == NULL)
                return posix_spawn(pid, file, fa, sa, cav, env);

POSIX says ...

	If this environment variable [PATH] is not defined, the results of
	the search are implementation-defined.

According to the manual, our implementation defined is to use _PATH_DEFPATH

According to our code, our implementation defined is to not search any PATH
when it is undefined, but simply use the filename given relative to $PWD.

Either of those is fine with POSIX - but we should really have one consistent
policy.   Changing either the manual or the code to match the other is also
easy.   What is not so easy is to decide which of the two (or perhaps
something else, like perhaps using the results from a lookup of
sysctl(user.cs_path)) we should actually do.

Opinions?

Aside: I started looking because POSIX is adding a "chdir" file action
to posix_spawn and posix_spawnp - and the path search (for relative paths)
done by posix_spawnp is to be applied after the effects of the chdir, which
would mean changes to our code.   They're also adding a fchdir() file action,
which my initial impression was would be impossible to support in
posix_spawnp() (no reliable way to find the name for the directory so as to
test 'x' permission on the potential pathnames generated from a PATH element
lookup relative to that directpory) - but now I think there might be a
way.    Anyway, that caused me to look at our posix_spawnp() implementation
leading to the discovery of this disparity between the doc and the code.

kre