VMS vs. UNIX file system
Erland Sommarskog
sommar at enea.se
Tue Sep 20 05:58:40 AEST 1988
Jamie Hanrahan (jeh at crash.CTS.COM) writes:
>I know, I know -- for many applications stream I/O makes for much cleaner
>program design. But for others, it doesn't, at least not when you have
>good alternatives available.
I don't think one should over-emphasize the importance of what I/O-
concept the OS uses. If I program in an high-level langauge it is
rather the I/O-concept of that language which is of interest. At
least if I/O is well-defined. In many modern langauges, I/O is not
part of the langauge, but rather a library which could be more or
standardized. What is left is of course the question of efficiency.
So if the langauge like C only has stream I/O (I assume it is so,
I don't speak C, so I could be wrong) then we don't benefit from
a complex file system when all we want is simple streams.
Ada, on the other hand, has text files, and record files both for
sequential and direct access. For the compiler-writer it may be
of interest if the file system supports the appropriate formats,
for me as a programmer it does not. Whether it's in the file system
or the RTL doesn't matter.
Jamie Hanrahan complained that stream I/O meant that in-band data
were used as a terminator. In practice this mean writing an LF in
the middle of a text line is impossible in Unix, while is quite OK
in VMS. (Which on the other hand impose a maximum length on the line.)
So what about Ada? If I write an LF character the result will be
different on VMS and Unix? Non-portable? Yes, but the manual also
clearly says that I/O of non-printable characters is not defined
by the language.
--
Erland Sommarskog ! "Hon ligger med min b{ste v{n,
ENEA Data, Stockholm ! jag v}gar inte sova l{ngre", Orup
sommar at enea.UUCP ! ("She's making love with best friend,
! I dare not to sleep anymore")
More information about the Comp.unix.wizards
mailing list