Re: [bug-diffutils] Diffutils 3.2 v. VMS

[Steven M. Schweda]

From: Paul Eggert <address@hidden>

> > I was trying to fix a specific
> > problem, and I don't know how many other instances of open() would be
> > affected/damaged by a global change.
> 
> That depends on what the problem was.  I don't know VMS.
> But if the problem affects one instance of open with
> those flags, why wouldn't it affect them all?

   It depends on which sort of file is being used, and how it's used. 
VMS has various record formats, not simply a stream of bytes.  In this
case, I had a specific complaint from a victim (with a specific type of
file) about "cmp", which I could fix by forcing stream access
("ctx=stm") in one place.  I didn't investigate to see how/if open() was
used elsewhere.  Perhaps a global change would be harmless, but my
testing is minimal (because I can't use the normal UNIX-oriented tests),
and I chose not to risk breakage elsewhere.

> >    This change is specific to the use of P_tmpdir (defined in <stdio.h>
> > around here),
> 
> Why not just fix P_tmpdir directly, then?  That'd be simpler,
> surely.  And it could be done in the stdio.h wrapper.

   The C RTL could probably deal with a UNIX-style file specification in
this case, but this temporary file spec is passed out in an external
editor command, which will be processed by DCL (and probably a VMS
editor), not a UNIX shell, and not the C RTL, so it must be a VMS-style
file spec.  Perhaps a UNIX-like file spec could be translated to a VMS
file spec first, but that's much more work that simply starting with a
VMS-style file spec.

> > Resurrecting
> > HAVE_WORKING_VFORK and its friends could allow hiding (or disguising)
> > some of the VMS specificity, but not much.)
> 
> Why not?  What's the difference between VMS vfork and
> (say) GNU/Linux vfork?  I'd rather resurrect that code,
> if VMS could be abstracted away, than to have code that's
> VMS-only vfork.

   Apparently, the big difference is in how the I/O file streams are
handled.  VMS is not UNIX, and it doesn't handle I/O file stream
inheritance the same way, hence decc$set_child_standard_streams(),
which helps glue things together.  As "HELP CRTL
decc$set_child_standard_streams" says:

         The decc$set_child_standard_streams function allows mapping of
         specified file descriptors to the child's stdin/stdout/stderr
         streams, thereby compensating, to a certain degree, the lack of
         a real fork function on OpenVMS systems.

The marvelous thing about a dancing bear is not that it dances so well,
but that it dances at all.

   VMS continues to require the VMS-specific code for this stuff.  The
only question is whether you'd be happier with "#ifdef __VMS" or
something more like "#ifdef HAVE_WORKING_VFORK" (which hides only the
"VMS" (in a few places), not the actual annoying code).

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547