[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch]lib/savewd working on OpenVMS

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]