Mail Archives: cygwin/1998/01/13/01:57:00
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".
- Raw text -