... but if POSIX has a close() I think there's no issue here - MSW is POSIX compliant, they say, and hence they're committeed to maintaining close(). So I think it's fine just to use close() and not have a sys_close() at all (or if someone is actually using sys_close() we choud just:
> int sys_close(int fd) > { > return close(fd); > } :) M On Tue, Dec 18, 2012 at 12:22:29PM -0500, Hans-Christoph Steiner wrote: > > On Dec 18, 2012, at 4:56 AM, IOhannes m zmölnig wrote: > > > On 12/18/2012 04:40, Hans-Christoph Steiner wrote: > >> > >> I think this approach works. > > > > thanks > > > >> The patch you provided seems totally untested, as in not even compiled on > >> GNU/Linux or Mac OS X. It includes the _close() function in sys_close() > >> which only works on Win32 and it gives this warning when building on Mac > >> OS X: > > > > thanks for the compliments :-) > > > > i can assure you that the code is tested as in "compiled without warning on > > gcc-4.7.2 on a debian/gnu linux (wheezy/sid) system" and has been > > field-tested and shown to be able to load externals that the old code has > > not been able to load. > > > > however, you are of course right that the use of "_close()" is indeed an > > oversight, which only did not trigger a problem so far, as sys_close() is > > nowhere used yet. > > > >> > >> s_path.c: In function ‘sys_open’: > >> s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through > >> ‘...’ > >> s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’) > >> s_path.c:450: note: if this code is reached, the program will abort > > > > > > the patch includes some comments pointing to an online discussion of the > > problem. to summarize: using mode_t in va_list will always trigger some > > problems. either we accept the warning (the code will never be reached, > > since a runtime-test will use a va_arg(..., int) instead) or we move the > > test to configure (autoconf). > > > > since i am the only one who seems to like autoconf, i decided for the less > > invasive solution. > > I think it makes sense to restore sys_close() for backwards ABI > compatibility. Microsoft says that the POSIX close() was deprecated in 2005, > and to use their ISO C++ _close() instead [1][2], so the new sys_close() > should look like this: > > > /* close a previously opened file > this is needed on platforms where you cannot open/close resources > across dll-boundaries */ > int sys_close(int fd) > { > #ifdef _WIN32 > return _close(fd); > #else > return close(fd); > #endif > } > > > And leave sys_open, sys_fopen, and sys_fclose as macros in the header. This > implementation of sys_open and warning are much more complicated. And tho > normally I think its good to avoid #ifdefs in headers, in this case I think > it actually communicates why we have these sys_open/sys_close > sys_fopen/sys_fclose in the first place: "Win32 lacks good POSIX API support, > everything else works as is". > > Attached is my patch that I think should replace > 2b8a4c13904f6b8bef3a8ae52b5258a131eb6a19 "provide sys_close(),... on all > platforms" > .hc > > > > [1] http://msdn.microsoft.com/en-US/library/ms235443(v=vs.80).aspx > [2] http://msdn.microsoft.com/en-US/library/5fzwd5ss(v=vs.80).aspx > > > >> (I attached the patch for reference, it doesn't seem to be up on the patch > >> tracker any more.) > >> > > > > it seems that the patch has moved to the "bug" tracker. > > i moved it back to "patches" [1]. > > > > > > fgmasdr > > IOhannes > > > > > > [1] > > https://sourceforge.net/tracker/?func=detail&aid=3596865&group_id=55736&atid=478070 > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev@iem.at > > http://lists.puredata.info/listinfo/pd-dev > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev