From: tiberius AT braemarinc DOT com (Gary R. Van Sickle) Subject: RE: Why text=binary mounts 13 Jan 1998 01:57:00 -0800 Message-ID: <01BD1F73.B08FDC00.tiberius.cygnus.gnu-win32@braemarinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "gnu-win32 AT cygnus DOT com" Hi Benjamin, I guess the point I was trying to make is that it doesn't seem to me that there is a good argument for there to be text processing functionality in the fopen() family of functions (I know, it's a little late now!). The difference I see between 'modes' and 'formats' is this: we don't have a JPG mode or a WAV mode in fopen(), so why do we have a text mode? When somebody wants to open up and manipulate a JPEG file, they use a JPEG library that gives them access to methods that are meaningful only on JPEG files. I see text files in the same way. If you want to read a line of text, it seems to me that the most logical thing to do would be to use a library which gave you access to functions such as fscanf() etc. which have no meaning for generic (binary) files. This library then would be the place to do things like making all text files look the same to the programmer whether they're DOS/UNIX/Mac/whatever, in the same way that a PCX library might 'gloss over' the differences between the different PCX versions. 'Doesn't work' may have been a little harsh. As you point out, it's been working for a lot of people for a long time now. It just seems to me that there's got to be a better way, and that the GNU world is the only place where it could actually be done. Just think of it - millions of programmers everywhere feeding \r\n's, \r's, \n's, HTML, Unicode, etc., into gcc's running on Linux, NT, Rhapsody, and yes, even DOS, and having no trouble in any configuration. Sounds like a magical dream world. Sorry, I'm getting carried away. You've got me thinking, though. How about this: we say, "we're stuck with text mode, we'll do better next time, but to alleviate the current situation, we take the TAL and put it in the fopen() functions, so that when somebody does a fopen(???, "rt"), they are getting the TAL sitting on top of a binary stream"? That way all the old programs which are ANSI-compliant (we've canned those that aren't) get the cool new 'any text file' functionality *automatically*. Plus, since the TAL is portable, any new GNUWin's or DJGPP's or whatever also get it automatically. This looks to me like it solves the problem in the way you were describing, but doesn't require the addition of another mode. Gary R. Van Sickle (tiberius AT braemarinc DOT com) Electrical Design Engineer Braemar Inc. 11481 Rupp Dr. Burnsville, MN 55337 (612) 890-5135 Ext. 144 Fax: (612) 882-6550 -----Original Message----- From: Benjamin Riefenstahl [SMTP:benny AT crocodial DOT de] Sent: Monday, January 12, 1998 3:54 AM To: gnu-win32 AT cygnus DOT com Subject: Re: Why text=binary mounts 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". - 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".