On 02/25/2011 04:12 PM, Paul Eggert wrote: >> That might be so now, but a month or a year from now, someone will >> decide that gnulib's `lstat' needs to fix some other anomaly, which >> will cause DJGPP builds of some package out there to use this code. > > Anyone who decides that should of course revisit this issue, > and it'll be their responsibility to make sure the anomaly > is handled correctly. This may use ISSLASH and may not; it's > hard to anticipate and any guesses we make about this now are > likely to be wrong.
Also, anyone that changes lstat had better also change test-lstat as part of the gnulib testsuite, which, if run on DJGPP, would quickly point out if we had introduced a regression. That said, I doubt that we'll do much to lstat any time soon; we've pretty much covered all the non-POSIX compatibility issues observed in the wild already. Rather, I think our next stat-related project in the coming year will be providing a working xstat() replacement for platforms, built on top of [fl]stat[at] where the native kernel support is lacking, and taking advantage of the possible speedups where the new kernel interface lets you avoid wasting time on collecting stat information that the program will just discard. Now if only the Linux kernel developers would finalize the xstat() interface... -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
