Pascal --> C question

[Dave Jones]

in article <225800016 at uxe.cso.uiuc.edu>, mcdonald at uxe.cso.uiuc.edu says:
> Nf-ID: #R:goofy.megatest.UUCP:302:uxe.cso.uiuc.edu:225800016:000:1556
> Nf-From: uxe.cso.uiuc.edu!mcdonald    Mar 21 07:58:00 1988
> 

[ Stuff about "flush" meaning different things in Unix and VMS:
  In VMS "flush" means "end-of-record", and "end-of-record" means '\n'. ]

>
> The VMS C compiler isn't broken.
> 

Oops!  You better tell them quickly, because a previous posting says that
it has been fixed in the next release!

I still don't know anything about VMS, but I can hardly take your advice
about not talking about it until I do.  Hell, if everybody had that
attitude, hardly anything would get said, ever!  It is true that "a
little knowledge is a dangerous thing," as is evidenced by the
majority of the postings to this group.  But I think that ignorance,
when freely admitted, is quiet benign.

So I offer these comments to be considered in view of may complete lack 
of competence in VMSisms: There is some little problem with mapping the 
semantics of stdio byte-streams (as defined by the Unix implementation) 
to the VMS record oriented files.  But making flush() synonymous with 
end-of-record, and inserting gratuitous newlines ain't part of the answer.

IBM -- or was it Whitesmith's -- had exactly the same problem porting 
the stdio library to VM/CMS, MVS, and MVS/XA.  They did a pretty good 
job of it.  See "C Language Manual", IBM publication SC09-1128-0, Chapter 9.
They defined an (almost) reversible mapping from the record oriented files onto
the (virtual) byte-streams of stdio. It's not perfect.  For example,
it is sometimes necessary to pad lines with blanks as they go into
record oriented files, and then remove trailing blanks as the record
oriented files are read as text-streams.  So trailing blanks which really
were in the stdio stream get discarded. Oh well...

The description of fflush() on page 11-83 says, "fflush drains any unwritten
data in the output buffer for the stream controlled by the FILE..."


		Dave Jones
		Megatest Corp.
		880 Fox Lane
		San Jose, CA.
		95131

		(408) 437-9700 Ext 3227
		UUCP: ucbvax!sun!megatest!djones
		ARPA: megatest!djones at riacs.EDU



"If it's really broken, go ahead and fix it."