Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!pasteur!ucbvax!CHEWI.CHE.WISC.EDU!christiansen
From: christiansen@CHEWI.CHE.WISC.EDU ("REED CHRISTIANSEN")
Newsgroups: comp.lang.c
Subject: VMS C file type and stdio - help!
Message-ID: <8809061834.AA29177@ucbvax.Berkeley.EDU>
Date: 30 Aug 88 16:51:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

In article <613@philmds.UUCP>, mcvax!hp4nl!philmds!leo@uunet.uunet (Leo
de Wit) writes:
>In article <351@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes:
>>In article <3689@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>   [Rahul's reply omitted]...
>>  [Larry's text omitted]...
>
> [Some of Leo's stuff omitted]...
>P.S. Why in the first place couldn't they [DEC] leave the library functions
>alone, instead of 'adding all those nice features' (see also extra
     The problem (if there is one) is that the vanilla-C file types
     aren't adequate to deal with files created outside of the C
     environment, as these were.  DEC could have put a crippled C
     on VAX/VMS, one that would not have the capabilities of their
     other languages, but they decided to supplement (NOT SUPPLANT) the
     Unix-style I/O.  You can still do Unix-style I/O...
>format types in printf, etc.)? The least they (DEC) should have done is
>warn inadvertent users of possible portability problems.
     They do.  Doesn't anybody read the user documentation?  Chapter 1 of
     the VAC C Run-Time Library Information manual dicusses portability
     issues in painful detail:  Section 1 of Chapter 1 discusses Unix I/O
     (and how to be compatible, if you wish); Section 4 of Chapter 1
     discusses many other portability concerns.  And, too, they devote an
     entire chapter (4) to Unix I/O.
>Lucky me to come from a Unix womb (and as such somewhat better aware of the
> problems) 8-).
     This isn't the first VMS question that could have been answered by
     people opening up the manuals and spending a few minutes to spin through
     them.