From: jqb AT netcom DOT com (Jim Balter) Subject: Re: ASCII and BINARY files. Why? 28 Jan 1997 14:41:07 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32EE5CD4.69DB.cygnus.gnu-win32@netcom.com> References: <199701281434 DOT BAA11080 AT mundook DOT cs DOT mu DOT OZ DOT AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: Fergus Henderson Original-CC: gnu-win32 Original-Sender: owner-gnu-win32 AT cygnus DOT com Fergus Henderson wrote: > > Jim Balter wrote: > > > > Stephan Mueller 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. -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".