Fw: Fw: Cpp patches for VMS

[Douglas B. Rupp]

----- Original Message ----- 
From: "Zack Weinberg" <zack@codesourcery.com>
| 
| Okay.  I've just spent the past half hour trying to make sense of the
| online documentation for VMS' file services.  I have not been able to
| find the crucial bit, which would be the explanation of which file
| format is generated and expected by VMS native text processors.

The file output format depends on the type of the previous version of the file
unless explicitly overridden.

| > Unix style paths are recognized by DECC RTL.
| 
| However, a user might reasonably expect GCC to do sensible things with
| VMS style pathnames, e.g. in an -I switch; and I don't think we do
| right now.

That's a huge can of worms to open and the wrong way to go in my opinion. VMS is
moving more towards Unix compatibility with each release, so there's no need to
try to support VMS style directory syntax.  A better way to handle it is to
have a wrapper around gcc to handle the syntax conversion, similar to the gnatcmd
program for ada.

| > 
| > Fwrite on VMS generates a new line at the end of every invocation
| > when writing to record oriented files. Only record oriented files
| > are shareable between parent/child processes so its not possible to
| > avoid them.
| 
| However, the CRTL manual makes it sound like it creates stream files
| by default, and we aren't setting any special flags in the call to
| fopen for the output file.
| 
| I can't make any sense at all of the rules for sharing files, etc.
| The model being used is too different from what I'm used to, and the
| documentation assumes you understand already.  I need a more detailed
| explanation.
| 

I think that's right, stream files are created by default unless there's an earlier
version and then that type is used.  Bash on VMS uses record oriented files, since
those are the only kind that can be shared, e.g. for I/O piping and it's reasonable
to expect gcc to be able to handle them.  If we were to try to
force the creation of a stream oriented file, it would then be impossible to
pipe it into another process under control of bash.  I think the nulls
previously mentioned are also an artifact of record oriented files, but I'm
trying to pin that down.