This is the mail archive of the cygwin-apps@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: Pending change to cygwin DLL and binmode/textmode musings


Pls see below
----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
To: <cygwin-apps@sourceware.cygnus.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


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