thanks david.
using dup() is very nice idea!
your code works with
CFLAGS=-D__DARWIN_64_BIT_INO_T # manual is wrong
and a fix:
// buf = ((char*)buf) + d_reclen(buf);
buf = (struct dirent *)(((char*)buf) + d_reclen(buf));
and adding
#define NAME_MAX 256
in somewhere.
now /dev is readable.
one problem is left.
my test code:
fd = open(dirname,OREAD);
if(fd < 0)
fatal("%s open error",dirname);
while((n = dirread(fd, &db)) > 0){
print("#DBG n=%d\n",n);
for(i = 0; i < n; i++)
print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid);
}
close(fd);
shows for dirname=$HOME
...
arch root 501
bin root 501
...
but they should be
arch arisawa staff
bin arisawa staff
this problem comes from _p9dir() that is used in dirpackage().
Kenji Arisawa
> 2017/04/08 18:07、David Arroyo <dr...@aqwari.net> のメール：
>
> Ignore my previous post, I was tired and forgot about dup(). How about
> something like this? (attached)
>
> I only tested this on Ubuntu, I don't have an OS X machine. I still went
> with readdir_r because the AIX and Solaris man pages for readdir were
> vague about its behavior when called from multiple threads (glibc, musl,
> FreeBSD look pretty safe).
>
> Cheers,
> David
>
> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
>> This should be doable with some combination of fdopendir(3) and
>> readdir(3). I'm not sure how to avoid leaking memory through the
>> returned DIR pointer and any memory allocated with by readdir(3).
>> This is usually free'd by closedir(3), which we can't use without
>> closing the underlying file.
>>
>> It should be OK to use free() on the return value of fdopendir, and
>> stick to the uglier readdir_r(3) interface. I can definitely see why
>> Russ went with the simpler system-specific interfaces on this.
>>
>> David
>>
>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
>>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote:
>>>
>>>> but how to?
>>>>
>>>> unix doesn’t have something like fdreaddir(int fd).
>>>> my guess: russ unwillingly used a low level function such as
>>>> int getdirentries(int fd, char *buf, int nbytes, long *basep).
>>>>
>>>> readdirall() might be OK in regular usage.
>>>
>>> I don't use OSX regularly, although I do maintain the syscall
>>> layer for Myrddin on it.
>>>
>>> Getdirentries64 exists, and rudimentary testing doesn't show
>>> any difficulties with using it.
>>>
>>> --
>>> Ori Bernstein
>>>
>>
> <posix-dirread.patch>
