Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Binary I/O on stdin/stdout?
Message-ID: <2541@bsu-cs.UUCP>
Date: 2 Apr 88 18:50:44 GMT
References: <302@goofy.megatest.UUCP> <225800017@uxe.cso.uiuc.edu> <7565@brl-smoke.ARPA> <8036@elsie.UUCP> <3221@haddock.ISC.COM> <2500@bsu-cs.UUCP> <3295@haddock.ISC.COM>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 60

In article <3295@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
[about VMS stream-LF files]
>The fact that it's called "stream-LF" (as distinct from "stream-CR" or just
>"stream") suggests that the newlines which terminate the records have some
>significance to the OS.  Is it legal, for example, to write 70000 characters
>without a newline?  If not, this doesn't seem like an acceptable format for
>binary mode.

Yes, a VMS C program can write any number of characters before writing
a newline, and it works, and it can all be read back.  VMS does handle
records of arbitrary length in stream-LF files, SO LONG AS ALL ACCESS
IS THROUGH THE VMS C LIBRARY.  Things break down, however, when such a
file is manipulated in any other manner, as is shown by the following
program.

-----cut here-----
#include <stdio.h>
/* testing VMS stream-LF format */
#define HOWMUCH 2000     /* how much to write as a single record */
#define FNAME "junk.dat" /* what to call the file */

main()
{
   FILE *f; int i; int c;

   f = fopen (FNAME, "w");
   if (f == NULL) 
      perror("write");
   for (i = 0;  i < HOWMUCH;  i++)
      fputc ('x', f);
   fputc ('\n', f);            /* terminates stream-LF record *whew* */
   fclose (f);

   /* now read file and dump to screen */
   f = fopen (FNAME, "r");
   if (f == NULL)
      perror ("read");
   for (i = 0; i < HOWMUCH + 1; i++) {
      c = fgetc (f);
      fputc (c, stdout);
   }
}
-----cut here-----

This program writes a 2000-character record to junk.dat, then reads
junk.dat and sends it to the screen.  I ran it both interactively and
under batch.

(a) Interactively:  What is printed on the screen by the program is
what I expected:  2000 'x' characters.  But when I gave the VMS command
"type junk.dat" I got a QIO error, presumably because the VMS "type"
command can't handle 2000-character records.

(b) Under batch:  The output from the program as shown in the batch log
was not 2000 'x' characters followed by a newline.  Instead, I saw
lines of 512 'x' characters.  Clearly, a newline was being forced after
512 characters at most.  When the batch file did "type junk.dat", a QIO
error occurred again.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi