Cpp patches for VMS

[Zack Weinberg]

On Sun, Nov 18, 2001 at 05:58:29PM -0800, Douglas B. Rupp wrote:
> From: "Zack Weinberg" <zack@codesourcery.com>
> |
> | If you could indicate which categories of file the VMS native text
> | editors handle, I think that would put a reasonable bound on the
> | categories GCC needs to handle.
> 
> 1) VMS Edit and VMS Emacs by default create this type of file if
> there is no previous version:
>
> File organization: Sequential
> Record format: Variable length
> Record attributes: Carriage return carriage control
>
> Stat size != read size

I begin to understand, now.  The stat size includes block padding, and
the NULs and the missing trailing newlines are because, for some
reason, the file isn't being properly translated from the on-disk
format to the stream format cpplib expects in memory.  I'll bet you
that is because we try to use mmap, and mmap bypasses the translation
operation.

As a test, could you try putting

#ifdef VMS
#undef HAVE_MMAP_FILE
#endif

just before the first "#ifdef HAVE_MMAP_FILE" in cppfiles.c, and
taking out the hacks for NULs and missing trailing newline?

> | Well, at the very least, we should (a) disable the clever pathname
> | simplification logic, and (b) make all the file name comparisons case
> | insensitive.  [DOS and Mac also want (b), so we should make that some
> | sort of generic hook.]
> 
> VMS 7.2 and above supports mixed case filenames. So the option
> for case insensitive comparisons has to be selectable.

Is it case *sensitive*, or just case *preserving*?

> C pipes on VMS aren't quite the same as on Unix, since the code in
> between a vfork and exec executes in the parent, not the child. So
> in order to emulate Unix pipes a shared temporary file (ideally on a
> ramdisk) has to be used.  This admittedly inefficient arrangement is
> currently how VMS bash emulates Unix pipes.

Augh yuck.  Why can't it just use mailboxes?  LIB$SPAWN purports to
let you redirect the input and output of the subprocess...

Incidentally, you might know this - the manuals give the strong
impression that DCL is capable of loading and executing a new "image",
then regaining control when it exits, *without* creating a subprocess
to do it in.  I can't find any routines that cause that to happen from
the compiled-program level, but it must be possible.  It would be a
good idea to make pexecute.c do that instead of trying to use
fork/exec.  (Weird, why does pexecute.c even compile?  It wants fork,
but the CRTL only has vfork.)

zw