Mail Archives: cygwin/2001/02/15/16:03:31
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);
}
-- _
= 'Net Address: http://www.cyberport.com/~tangent | / \ ASCII Ribbon
= ICBM Address: 36.82740N, 108.02040W, alt. 1714m | \ / Campaign
= | X Against
= Chance favors the prepared mind. | / \ HTML Mail
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -