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