Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
list-help: <mailto:cygwin-apps-help AT sourceware DOT cygnus DOT com>
list-post: <mailto:cygwin-apps AT sourceware DOT cygnus DOT com>
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-apps AT sourceware DOT cygnus DOT com
Message-ID: <003401bfdf07$3f5196e0$f7c723cb@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-apps AT sourceware DOT cygnus DOT com>
References: <20000624234013 DOT A29970 AT cygnus DOT com> <005601bfde69$c66fa0c0$f7c723cb AT lifelesswks> <20000625120826 DOT C790 AT cygnus DOT com>
Subject: Re: Pending change to cygwin DLL and binmode/textmode musings
Date: Mon, 26 Jun 2000 10:41:16 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Pls see below
----- Original Message -----
From: "Chris Faylor" <cgf AT cygnus DOT com>
To: <cygwin-apps AT sourceware DOT cygnus DOT com>
Sent: Monday, June 26, 2000 2:08 AM
Subject: Re: Pending change to cygwin DLL and binmode/textmode musings


> On Sun, Jun 25, 2000 at 03:54:01PM +1000, Robert Collins wrote:
> >I like the idea of a database of files... that would mean less porting
> >issues, particularly with programs that act on files in common with other
> >tools.
>
> Personally, I don't like the thought of maintaining a list.  I think we'll
> constantly be saying "Update your /etc/filemodes to the newest version".

...instead of please update <tool with text mode bug of the month>? Which is
easier/more/less error prone?

> And, as the file grows larger it will take time to parse, slowing down
> every cygwin application.  I guess we could get around that by setting
> some kind of flag in the executable but if we are going to do that then
> why not just record the filenames in the executable itself.

a) Well I think what's really under discussion is some sort of new file
attribute - and with a hash table on the name of the file the lookup would
stay very quick for reasonable numbers of files. (check list file date, if
modified rebuild hash table, otherwise just lookup). that wouldn't work if
you were planning wildcards like
  set_default_open ("/*/*.c", O_BINARY);
but I sure a reasonably fast implementation could be designed.
b) As we are only talking about setting defaults for the common files on the
system, the number of files in list w/wildcards should not get beyond a
couple of hundred anyway, and a non-wildcarded database could uses hashes.

> I'd rather have the programs operate correctly without external
> dependencies.

I agree with this, but no file stands on it's own - look at the amount of
(excellent) work done to date on cygwin... that is an external dependency. I
believe minimising the changes needed to move source between platforms is a
Good Thing.

> Of course, there is nothing stopping us from using both methods.

ditto.

> cgf

One benefit of an external database that I missed before is that when folk
download un-cygwinised source that compiles and runs with only text-mode
issues, the problem will be caught _by the platform_.. no questions needed
on the mailing lists. Here is where a wildcard or perhaps a regex style
definition in an external database could be very useful...ie
====file starts======
[O_TEXT]
/.*\.c
/.*\.h
/.*\.cpp
/.*[Mm]akefile
[O_BINARY]
/.*\.o
/.*\.a
======file ends=====
Rob