VMS C file type and stdio - help!

REED CHRISTIANSEN christiansen at CHEWI.CHE.WISC.EDU
Wed Aug 31 02:51:00 AEST 1988


In article <613 at philmds.UUCP>, mcvax!hp4nl!philmds!leo at uunet.uunet (Leo
de Wit) writes:
>In article <351 at sdrc.UUCP> scjones at sdrc.UUCP (Larry Jones) writes:
>>In article <3689 at bsu-cs.UUCP>, dhesi at 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.



More information about the Comp.lang.c mailing list