From: benny AT crocodial DOT de (Benjamin Riefenstahl) Subject: Re: Why text=binary mounts 12 Jan 1998 10:08:48 -0800 Message-ID: <34B9E82D.F3E1239E.cygnus.gnu-win32@crocodial.de> References: <01BD1D1B DOT 99116B20 DOT tiberius AT braemarinc DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "gnu-win32 AT cygnus DOT com" Hi Gary, Benjamin Riefenstahl wrote: [proposal to add new modes to fopen(), open(), iostream to cater for Unix/DOS/Mac text files] Gary R. Van Sickle wrote: > The real problem here is that files as they exist on disk don't have > 'modes', they have formats. Adding 'modes' to a system that really doesn't > work already will only make the situation worse. ?? Sounds nice, but what does that really mean ;-) (no offence intended). As I see it "file format" vs "stream translation mode" is just a matter of point of view. Folks may not be used to file streams doing translations on Unix but on other systems it's a fact of life and seen as a feature. I'm also not sure what "doesn't work" means. Text mode works very well in DOS with other compilers. Porting simple Unix tools dealing with binary files usually amounts to putting in the O_BINARY or "b" flags and that's that. It's an easy patch (bug fix actually) and no problem at all as far as I can see, except that text mode does not cover Mac files. > What I think is really needed is a Text Access Library (TAL) that sits *on > top* of a *binary* stdio file and reads and writes lines from UNIX, DOS, > Mac, maybe HTML, etc., etc., text files. Instead of fopen(???, "rt"), > you'd use the library and then *not care* what the text file format is, > only that it contains lines of text. This TAL would become part of the > standard C library (or the GNU library at least, which would make it a > de-facto standard), all the tools that were dealing with text would use it, > and eventually the "t" functionality of stdio would be deprecated and the > problem would be solved. There is already at least one library framework that can do this and more, I'm thinking of I/O Streams. With I/O Streams I would just have to define my special UniversalTextInputFilterStream, plug it into the program where it used to declare it's text input streams, and I would be done. Yeah sure, it's C++ only but for a new design that would not bother me. The problem with both approaches (I/O Streams as well as your TAL) is that they don't cover existing tools written in C on the basis of fopen() or even open(). There would be significant amount of work to be done to port these. And that was where I thought a simple re-definition of the existing library feature "text mode" (which I otherwise accept as given) would help a lot to simplify this work. BTW I'm not dismissing the idea of TAL in general. In theory I would be interested in an extensible stream/filter library for C as a GNU project or even in the C RTL. In practice though I program in C++ and already have what I need there. so long, benny ====================================== Benjamin Riefenstahl (benny AT crocodial DOT de) Crocodial Communications EntwicklungsGmbH Ophagen 16a, D-20257 Hamburg, Germany - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".