|
From: | John E. Malmberg |
Subject: | Re: [patch]lib/savewd working on OpenVMS |
Date: | Mon, 3 Jul 2017 16:45:33 -0500 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |