Post by Paul Eggert Post by John E. Malmberg
OpenVMS does not have a fork() call and savewd.c is one of the few
cases where the OpenVMS vfork() call can be directly substituted.
This is true only if the application limits itself to a fairly
restrictive set of actions between the savewd_chdir and the
savewd_restore, no? For example, the caller to savewd_chdir cannot
return before calling savewd_restore. If so, these restrictions should
be documented in a brief savewd.h comment to the effect, "To be portable
to OpenVMS, callers to savewd_chdir and savewd_restore should respect
the following constraints: ...."
Those constrains are something that I will need to find out when I get
to running tests on the compiled modules.
With vfork() on OpenVMS, all local automatic variables, even those with
a volatile-qualified type, can have indeterminate values if they are
modified between the call to vfork() and the corresponding call to an
The OpenVMS C run-time library does not document what happens if you
make a second call to vfork() with out calling an exec function.
The above change savewd.c is what I made to the module to get the
coreutils package building and running, along with adding quite a bit of
OpenVMS specific code to handle other portability issues.