On 7/3/2017 4:07 PM, Paul Eggert wrote:
On 07/03/2017 03:30 PM, John E. Malmberg wrote:
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 exec routine.

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.

Regards,
-John

Reply via email to