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 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".


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