Mail Archives: cygwin/2001/02/15/18:20:00
On Thu, Feb 15, 2001 at 04:09:46PM -0500, Larry Hall (RFK Partners, Inc) wrote:
>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.
Egor has already submitted a patch like this and I've been mulling it
over for... a year maybe?
I think I can actually change Cygwin to do the right thing here without
any new API changes.
Stay tuned.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -