Re: Encodings. Paul Schlie (13 Feb 2004 02:18 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 03:35 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 05:59 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 06:36 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 08:00 UTC)
Re: Encodings. Robby Findler (13 Feb 2004 15:01 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 17:16 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 18:19 UTC)
Re: Encodings. Robby Findler (16 Feb 2004 01:03 UTC)
Re: Encodings. Paul Schlie (16 Feb 2004 03:21 UTC)
Re: Encodings. Paul Schlie (16 Feb 2004 04:18 UTC)
Re: Encodings. Robby Findler (16 Feb 2004 04:33 UTC)
Re: Encodings. bear (13 Feb 2004 17:40 UTC)
Re: Encodings. Per Bothner (13 Feb 2004 18:34 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 19:02 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 19:05 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 19:48 UTC)
Re: Encodings. Per Bothner (13 Feb 2004 19:11 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 19:44 UTC)
Re: Encodings. bear (13 Feb 2004 21:42 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 21:54 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 23:45 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 00:04 UTC)
Re: Encodings. bear (14 Feb 2004 01:06 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 01:08 UTC)
Re: Encodings. Paul Schlie (14 Feb 2004 02:35 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 03:00 UTC)
Re: Encodings. Paul Schlie (14 Feb 2004 03:04 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 03:08 UTC)
Re: Encodings. Paul Schlie (14 Feb 2004 03:29 UTC)
Re: Encodings. Paul Schlie (14 Feb 2004 02:19 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 03:04 UTC)
Re: Encodings. Paul Schlie (14 Feb 2004 03:10 UTC)
Re: Encodings. Bradd W. Szonye (14 Feb 2004 03:12 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 22:41 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 17:55 UTC)
Re: Encodings. Paul Schlie (13 Feb 2004 18:42 UTC)
Re: Encodings. Bradd W. Szonye (13 Feb 2004 18:53 UTC)
Re: Encodings. Ken Dickey (13 Feb 2004 21:53 UTC)
RESET [was Re: Encodings] Ken Dickey (14 Feb 2004 16:19 UTC)
Re: RESET [was Re: Encodings] bear (14 Feb 2004 18:02 UTC)
Re: RESET [was Re: Encodings] Bradd W. Szonye (14 Feb 2004 19:38 UTC)

Re: Encodings. Bradd W. Szonye 14 Feb 2004 00:04 UTC

Paul Schlie wrote:
> Just a nit, but a text file is a binary file ....

No, that is not true on all systems. There are systems where you simply
cannot access a text file as a "binary file" (a stream of bytes).

> More sophisticated indexed record file structures supported by some
> os's are themselves not much more than an intermediate primitive
> indexed data base built on top of plan old files composed of disk
> sectors, often with the knowledge of the storage systems blocking
> architecture for efficiency; but the general rule remains, you get out
> literally what you put in, as otherwise they wouldn't be very useful.

Yes, you get out what you put in. However, when a system provides no
"binary mode" or "stream mode" for text files, there is no way to
implement a text port in terms of a binary port.

To put it another way, a "binary file" is just a specific way of
organizing data on disk, designed so that you can access individual
bytes or words as a stream or in random order. UNIX systems store text
files that way, such that binary files and text files are actually the
same thing. On that kind of system, you can implement text ports on top
of binary ports.

But some systems do not store text files that way. There simply are no
operating system primitives to access them as a stream of bytes, and it
would not make sense to implement text ports in terms of binary ports.
That's why C has separate text and binary I/O modes. On UNIX-like,
ASCII-based systems, the two modes are identical, because "transforming"
binary data to text is a no-op. On DOS-like systems, text mode is
implemented as a filter on top of binary mode, like you suggest. (That's
also how it works on UNIX-like systems that use multibyte character
sets.) But on systems where text and binary data are fundamentally
different, the two I/O modes are independent.

While they're both ultimately bits on a spinning magnet, the interface
to those bits is often very different depending on the type of data. At
one time, the UNIX-like systems were the exception, not the rule. Now
it's the other way around, but the byte-stream model is still not
universal. Unless you really want to limit all I/O to that model
(i.e., make it impossible to implement Scheme on some systems), you
cannot design the system so that text I/O is a stream layer atop binary
I/O.
--
Bradd W. Szonye
http://www.szonye.com/bradd