Re: Optimizing away "ReadFile" calls when Make calls stat()

[Larry Hall (RFK Partners, Inc)]

At 02:47 PM 2/15/2001, Warren Young wrote:
>Egor Duda wrote:
> > 
> > the  only problem with this approach i can see is that if we introduce
> > new  API  and applications start to use it we became "bound" to it and
> > it'll  be  not too easy to deprecate ad remove it afterwards. OTOH, we
> > can  always  make stat_lite() a simple wrapper to stat() if the latter
> > become fast enough.
>
>I like the idea of stat_lite(), and I don't see a reason to ever
>deprecate it: it's simply a fact that stat() is a bad interface to Win32
>functionality.  It exposes a Unix filesystem's inode element, and
>therefore makes programs dependent on it.  To eliminate the need for a
>stat_lite(), you'd have to redesign Win32, which is out of our hands.
>
>Here's how I think stat_lite() should be designed: give it one extra
>parameter, a bitfield, over regular stat().  This declares what fields
>are important to the caller.  
>
>All the code in the DLL's current stat() implementation would move to
>stat_lite().  Then add 'if's checking the bitfield flags before making
>Win32 calls to look up field values.  The DLL's stat() implementation
>then becomes a wrapper around stat_lite(): it just sets all the bitfield
>flags, telling it to look up every field value.
>
>If this design is used, stat_lite() would be a misleading name.  How
>about stat_select(), since it would behave like select(2)?
>
>Example code:
>
>         struct stat st;
>         stat_select("foo", &st, ST_MODE | ST_MTIME);
>
>Cygwin.DLL:
>         int stat(const char* file, struct stat* pst) 
>         {
>                 return stat_select(file, pst, 0xFFFFFFFF);
>         }



Sure, this is an idea for new, Cygwin specific code.  I'm not quite 
sure why someone who was writing new code (or changing old) wouldn't just
use Win32 APIs to accomplish the required task though.  I mean, so long as 
the change results in non-portable code, why not pick the less specific 
Win32 APIs (over some Cygwin-specific alternative)?  Still, if you want to 
implement such a patch and submit it, I'm sure it will get some thoughtful 
consideration.



Larry Hall                              [EMAIL PROTECTED]
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple