From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles S. Wilson" To: "Larry Hall (RFK Partners, Inc)" Cc: cygwin@sources.redhat.com Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() Date: Thu, 15 Feb 2001 14:17:00 -0000 Message-id: <3A8C5599.EA52B4EC@ece.gatech.edu> References: <4.3.1.2.20010213134821.019a7130@pop.ma.ultranet.com> <20010213190131.14369.qmail@lizard.curl.com> <200102131935.OAA09136@envy.delorie.com> <20010213194612.17311.qmail@lizard.curl.com> <200102131954.OAA09284@envy.delorie.com> <20010213152313.A12830@redhat.com> <39319402546.20010214110838@logos-m.ru> <4.3.1.2.20010215160534.04a66d40@pop.ma.ultranet.com> X-SW-Source: 2001-02/msg00934.html "Larry Hall (RFK Partners, Inc)" wrote: > > 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. If I were porting an old app from unix to cygwin, and wanted to tune performance, I'd much rather do this: #ifdef __CYGWIN__ stat_select("foo", &st, ST_MODE | ST_MTIME); #else stat("foo", &st); #endif Than this: #ifdef __CYGWIN__ lots of ugly Windows stuff here populate a fake st structure (if I don't do this, then I need lots more #ifdef blocks in other parts of the code that references st->mode, etc.) #else stat("foo", &st); #endif > 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)? I might not want to #include windows.h (which *REQUIRES* me to also #define _WIN32 or compile with 'gcc -mwin32'.) I might not want to collude my native-win32-specific stuff with cygwin-specific stuff (which will happen if I'm forced to #define _WIN32) > Still, if you want to > implement such a patch and submit it, I'm sure it will get some thoughtful > consideration. I certainly hope so. --Chuck -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple