RStallworthy@PCO-MULTICS.HBI.HONEYWELL.COM (10/15/88)
In looking at the section (4.9.2) on "streams", it refers to streams of two types, "binary" and "text". Elsewhere it refers to binary files and text files, as if there were two distinct file types, such that a binary file could only be read / written as a binary stream and a text file could only be read / written as a text file. Now I am aware that the standard does not require this to be the case, but is there anything in the standard that would prevent it from being implemented in this way. Such an implementation would make it very difficult to write a program like "od", because you would not be able to get at the internal representation of a text file (on a non-UNIX system where the internal representation of lines is not just new-line characters separating the lines). Similarly, it seems to me that all disk files should be readable as a binary stream, however, again I am having trouble finding anything in the standard that would require this of an implementation to be conformant with the standard.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/23/88)
In article <881014204352.505039@PCO-MULTICS.HBI.HONEYWELL.COM> RStallworthy%PCO@BCO-MULTICS.HBI.HONEYWELL.COM writes: >In looking at the section (4.9.2) on "streams", it refers to streams of >two types, "binary" and "text". Elsewhere it refers to binary files >and text files, as if there were two distinct file types, such that a >binary file could only be read / written as a binary stream and a text >file could only be read / written as a text file. Now I am aware that >the standard does not require this to be the case, but is there anything >in the standard that would prevent it from being implemented in this >way. Nope. An attempt to open a file may fail for any reason the implementation chooses, including fopen() mode not matching the inherent file type. Naturally, an implementation that can do a better job should be encouraged to do so, but that is what X3J11 terms a matter of "quality of implementation".