Re: Problem with VMS Carriage return carriage control files in 5.10 and 5.12

Hi Craig,

I saw this a week or so ago but didn't have time to respond earlier ... I
hope this message is still useful.

>This is right after the perlio layer has called down to the unixio
>layer to get the file open.  We have an fd, so we can do an fstat() on
>that and retrieve the record format from the VMS-specific bits of the
>stat structure.  Then I check to see if it's a regular file (not a
>device like a mailbox that may need to carry binary data) and that the
>record format is either variable or variable with fixed control.  If
>these conditions are met, I enable the line buffering option on that
>filehandle.

So far so good ...

>I have tested this and it works for situations similar to Martin's
>original report, and it does not introduce any new test failures in
>the test suite.  But what situations, if any, does this break?  I'm
>assuming that if the record format is FAB$C_VAR or FAB$C_VFC, the
>records will never contain binary data with embedded newlines.  Is
>that true?   What other assumptions am I making that I shouldn't?

The great advantage of the VAR and VFC formats (compared to the various
Stream formats) is that you *can* have embedded newlines and other non-
printable characters in the record.  So it's quite conceivable that a
program might right "binary" data to a VAR or VFC file.  On the other
hand it would not be common Perl practice to do so.

When I'm writing programs I assume that each 'print' statement will result
in one output record.  I susppose you could arrange for each 'print' to be
followed by a flush to disk at that point, but of course performance would
probably suffer.

Just my 2c worth.

Regards,

	Jeremy Begg