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