[patch]lib/savewd working on OpenVMS

[John E. Malmberg]

Hello,

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.

Regards,
-John

[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: ...."

[John E. Malmberg]

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
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

[Paul Eggert]

Post by John E. Malmberg
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.

All that is fine, but savewd.h needs to document these constraints from
the point of view of the callers of savewd_chdir and savewd_restore, not
from the point of view of someone who knows implementation details.
Callers should not even need to know that vfork might be used.

Post by John E. Malmberg
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.

Yes, but the idea is that the savewd.c change should be documented.