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)
|
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