On Feb 22 13:21, Christopher Faylor wrote:
> On Wed, Feb 22, 2006 at 06:16:25PM -, Dave Korn wrote:
> >On 22 February 2006 17:31, Christopher Faylor wrote:
> >>On Wed, Feb 22, 2006 at 08:21:48AM -0800, Brian Dessent wrote:
> >>>I think implementing openat() directly would be the clear win here,
On Wed, Feb 22, 2006 at 06:16:25PM -, Dave Korn wrote:
>On 22 February 2006 17:31, Christopher Faylor wrote:
>>On Wed, Feb 22, 2006 at 08:21:48AM -0800, Brian Dessent wrote:
>>>Eric Blake wrote:
and/or have openat() implemented directly in cygwin so that the openat
emulation of open("/p
On 22 February 2006 17:31, Christopher Faylor wrote:
> On Wed, Feb 22, 2006 at 08:21:48AM -0800, Brian Dessent wrote:
>> Eric Blake wrote:
>>> and/or have openat() implemented directly in cygwin so that the openat
>>> emulation of open("/proc/self/fd/4/..") is avoided (not to mention more
>>> effi
On Wed, Feb 22, 2006 at 08:21:48AM -0800, Brian Dessent wrote:
>Eric Blake wrote:
>>and/or have openat() implemented directly in cygwin so that the openat
>>emulation of open("/proc/self/fd/4/..") is avoided (not to mention more
>>efficient by avoiding several other syscalls during the emulation).
Eric Blake wrote:
> and/or have openat() implemented directly in cygwin so that the
> openat emulation of open("/proc/self/fd/4/..") is avoided (not to
> mention more efficient by avoiding several other syscalls during
> the emulation).
I think implementing openat() directly would be the clear wi
CVS coreutils has recently provided emulation of the *at()
functions available in Solaris and recent glibc for other
platforms without them. The *at functions are nice because
you can recurse through directories without changing
the current working directory, which adds a measure
of thread-safety
6 matches
Mail list logo
