Mail Archives: cygwin/1997/01/28/14:41:07
Fergus Henderson wrote:
>
> Jim Balter wrote:
> >
> > Stephan Mueller <smueller AT MICROSOFT DOT com> writes
> >
> > > IMO, the only way to truly solve this problem once and for all is to
> > > gradually incorporate text/binary mode awareness into the official GNU
> > > sources.
>
> Yes, I agree.
>
> > > That means that all fopens that really mean to open in binary
> > > should have the 'b' added, and all code that follows fopens that really
> > > mean text mode should be examined and changed if they assume things like
> > > 'the size of the file equals the number of charcters in a read of the
> > > whole file'. The code isn't 'bad' the way it is, it's just
> > > Unix-centric, and not entirely ANSI conformant.
> >
> > Of course it's Unix-centric; it's GNU code, and GNU project is a Unix
> > emulation.
>
> Yes, of course, that explains the historical reasons.
> But this is the GNU-win32 mailing list: we're trying to port GNU
> software to Windows.
But the point was about "gradually incorporate text/binary awareness
into the official GNU sources", not about a Windows system.
The official GNU sources are for a GNU system, which is POSIX
conformant. The POSIX specifically states that there is no distinction
between text and binary mode. GNU code is written to take advantage of
that specification. This isn't just history, it is a matter of
efficient and managable coding, of coding to a standard. It is also
a matter of GNU policies, which are largely driven by Richard Stallman.
> > > It will be more useful
> > > and more portable if these things are fixed, and I'm sure in time they
> > > will be.
> >
> > Why be sure of something that's probably false?
>
> Le me repeat: we're trying to port GNU software to Windows.
> Do you have a better suggestion on how to do this?
I'm not sure you are reading carefully. There is no reason to be
"sure" that the GNU project will make these changes, regardless of
what the best suggestion is.
But yes, I suggest that the approach that has been taken by AT&T's
UWIN, of abandoning the text/binary distinction altogether,
is the best, most robust, lowest surprise factor, lowest cost
approach. Files that contain CR's can be filtered, and/or the library
could allow a special name form such as dos:filename that causes it to
open the file in "text" mode. The idea of letting programs decide
whether their files are text or binary does not work well, because
the unix tool philosophy is that files are arbitrary streams, and
so all the unix tools should default to binary mode anyway. And if
you add a binary or text flag to them, then you need to know file by
file what its format is, in which case the dos:filename method
would achieve the same thing in a much more consistent manner without
having to modify all the sources.
The *worst* suggestion is to ask people to start submitting patches
before having thought it through, conferred with the GNU folks,
and established guidelines. The GNU folks have coding guidelines
that must be adhered to, and one of the guidelines has to do with
consistency among flags to the utilities.
> > The GNU project has limited goals, and they explicitly do not include
> > [...] systems that have separate text and binary modes
>
> Yes, the GNU-win32 project's goals are not the same as the GNU project's
> goals. So?
So the issues here was "official GNU sources". Sheesh.
> > Notably, in POSIX systems, reading as many bytes from a file as stat says it
> > contains is perfectly appropriate behavior, and GNU code won't be "dumbed"
> > down for the sake of non-POSIX systems.
>
> "Why be sure of something that's probably false?"
> GNU code probably *will* be "dumbed down" for the sake of non-POSIX
> systems, because (a) that seems to be the only way to achieve the
> GNU-win32 project's goals and hence
The GNU project isn't interested in GNU-win32, and it isn't the
only way to achieve the project's goals.
>(b) the GNU-win32 developers will
> supply the GNU code maintainers with patches to make it work on
> GNU-win32
The GNU project doesn't accept arbitrary patches to the utilities
to get them to run on DOS, System 7, plan 9, VMS, etc. etc.
> and (c) most of the GNU code maintainers will be quite happy
> to incorporate patches that make their software more portable,
The GNU code has a portability target, and that is a unix target,
not a Windows target. The target explicitly rules out 16-bit
systems, non-unix filenames, and so on. Only certain standalone
pieces, such as emacs, are ported more widely.
> [not to mention the fact that (d) the GNU code maintainers and the
> GNU-win32 developers often one and the same, namely Cygnus].
Cygnus doesn't set GNU policy, and the GNU-win32 project is a bastard
child of cygnus, not a product.
> Even if there are a few recalcitrant GNU code maintainers
> who refuse to accept these patches,
It is not a matter of "recalcitrant GNU code maintainers", it is a
matter of *policy*. And you will find that Richard Stallman can be
quite "recalcitrant".
> that doesn't matter too much
> *because it is free software* --- you can get the source and apply the
> patches yourself.
The issue was "**official** GNU sources". Of course you can
get the sources and do what you want with them, and the cygwin people
have, but that's not the point I responded to. Sheesh.
--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -