On Sat, Jul 6, 2013 at 4:31 AM, Roland Mainz <[email protected]> wrote:
> On Thu, Jul 4, 2013 at 7:47 AM, Roland Mainz <[email protected]> wrote:
>> On Wed, Jul 3, 2013 at 2:06 AM, Roland Mainz <[email protected]> 
>> wrote:
>>> On Tue, Jul 2, 2013 at 8:04 PM, Roland Mainz <[email protected]> 
>>> wrote:
>>>> On Tue, Jul 2, 2013 at 4:11 PM, Irek Szczesniak <[email protected]> 
>>>> wrote:
>>>>> On Sun, Jun 30, 2013 at 11:53 PM, Roland Mainz <[email protected]> 
>>>>> wrote:
>>>>>> 2013/6/28 Glenn Fowler <[email protected]>:
> [snip]
>> Attached (as "astksh20130628_solaris_fixes003.diff.txt") is an updated
>> version of the patch which fixes the issues which came up during code
>> review:
>> - Fixed error handling in cd(1) for NFSv4/CIFS/SMBFS XATTR directories
>> - Opening the history files now goes through the
>> |*at()|-emulation&&intercept code to make sure extra flags+signal
>> restart is handled properly (tested)
>>
>> BTW: No, going through the |*at()| emulation is not slower unless the
>> |fd| argument in |openat(fd,...)| differs between individual calls
>> (well... at least the code in
>> http://svn.nrubsig.org/svn/people/gisburn/code/openat_emu/openat_emu.c
>> did maintain a cache (which is valid until |fchdir()|/|chdir()| is
>> called) and AFAIK the |*at()|-emulation in libast should do the same).
>
> ... one remaining issue came up during review... some code in
> src/cmd/ksh93 (besides globbing and directory reading) still uses
> |sfopen()| ... are there ant objections that I switch them over to
> |sfopenat()| with this patch already (we have to do it anyway in the
> future to wean-off Shell_t objects from relying on the global cwd) ?

No objection here. IMO all calls to obtain a file descriptor should go
through openat() because the reasons you've stated, plus the reason
that open() on such platforms is a libc wrapper which calls
openat(AT_FDCWD,name,flags,...).

Irek
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to