Where should the type information be 134

Nick Maclaren

OK, under the clarified question the answer is yes, including unit record file systems supporting only fixed length records.

So what? The definition of a file system (FS) line need not match the definition of an application line. It simply calls for an intermediate layer of buffering and translation. I'm sure you've the koan "Any software problem can be solved by the addition of another layer of indirection".

Character set issues are harder to handle efficiently, but no where near impossible. They just require a many:1 translation. Do you recall the rules for line termination on a 60-bit CDC? Two 6-bit '-' characters in poisitions 8 and 9 within a word. Talk about arbitrary and capricious!

The Wang systems had similar problems with charcter sets, so much so that not only were there "characters" that could not be generated from the keyboard, they also had caracters that could not be represented by an 8-bit hexadecimal code.

C-style stream IO is still possible on both of those platforms. It's just ugly (at the level of Medusa ugly).

Hardly. They just need another layer of translation. Given two representations of the same information a small set of utilities can handle the conversion from one to another. And those convesion functions can be referenced from within the C run-time so that applications desiring the platform representation can do so by setting an IO mode on the pseudo-stream.

Translation betweenn (unix),r (mac), andr-n (cp-m) works exactly this way.

You can, but not easily.

GFY. The existence of bad implementations does not demonstrate the impossibility of reasonably good implementations.

I'd need more explanation in order to understand the fflush() problem. In general you are indicating a need for commit and rollback with fflush() acting as a kind of commit. How does the system inhibit that?

tj3