This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Why text=binary mounts


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@braemarinc.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@crocodial.de]
Sent:	Monday, January 12, 1998 3:54 AM
To:	gnu-win32@cygnus.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@crocodial.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@cygnus.com" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]