[EMAIL PROTECTED] wrote:
> >Do you mean:
> >
> > sprintf(buf, "/proc/self/fd/%d/%s", dfd, dname);
> > dp = opendir(buf);
>
> Yes.
>
> >> Not sure why you have all the dup's in there.
> >
> >Because closedir() will also close the fd passed to fdopendir()
> >and I need the fd for a reliable
>[EMAIL PROTECTED] wrote:
>
>>
>> >Linux started to support openat() recently and for this reason,
>> >the best way of implementing a portable way of directory search without
>> >path length limitation is to use:
>> >
>> >ndfd = openat(dfd, "dname", O_RDONLY);
>> >close(dfd);
>> >dfd = ndfd;
>> >d
[EMAIL PROTECTED] wrote:
>
> >Linux started to support openat() recently and for this reason,
> >the best way of implementing a portable way of directory search without
> >path length limitation is to use:
> >
> >ndfd = openat(dfd, "dname", O_RDONLY);
> >close(dfd);
> >dfd = ndfd;
> >dp = fdopendi
>Linux started to support openat() recently and for this reason,
>the best way of implementing a portable way of directory search without
>path length limitation is to use:
>
>ndfd = openat(dfd, "dname", O_RDONLY);
>close(dfd);
>dfd = ndfd;
>dp = fdopendir(dup(dfd));
Interesting is, of course, th
[EMAIL PROTECTED] wrote:
>
>
> >Either approach (opendir()/dirfd() or open()/fdopendir())
> >might be handy on Solaris or anything else that has openat(),
> >for use with multithreaded programs.
>
>
> (To be honest, our next revision of rm will store both an fd and a DIR*;
> with dirfd() it would
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> >
> > A function like dirfd() is probably needed for
> > completeness and
> > compatibility, though I wonder what people are using
> > it for
>
> Supposedly to do an opendir() then convert the result to
> something they could use with fchdir(
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> > Strictly conformant to the above would therefore be:
> >
> > #define dirfd(dp) ((dp) ? (dp)->dd_fd : -1)
> >
> > You'd still crash if you pass an invalid pointer,
> > though.
>
> Regardless of one's opinion on checks for NULL args,
> Strictly conformant to the above would therefore be:
>
> #define dirfd(dp) ((dp) ? (dp)->dd_fd : -1)
>
> You'd still crash if you pass an invalid pointer,
> though.
Regardless of one's opinion on checks for NULL args, as a macro,
that's bad, with multiple references to the arg on
Frank Hofmann writes:
> On Thu, 22 Mar 2007, Richard L. Hamilton wrote:
> > The dirfd( ) function may fail if:
> > [EINVAL] The dirp argument does not refer to a valid directory stream.
>
> Will they really go for that ?
>
> I mean, the explicit "NULL exception" is one thing, but claiming that th
On Thu, 22 Mar 2007, Richard L. Hamilton wrote:
And to try to answer my own question, Draft 2 says
(about dirfd() among others):
...shall be declared as functions and may also be defined as macros. Function
prototypes shall be provided.
and specifically about dirfd():
The dirfd( ) function ma
>And to try to answer my own question, Draft 2 says
>(about dirfd() among others):
>
>...shall be declared as functions and may also be defined as macros. Function
>prototypes shall be provided.
>
>and specifically about dirfd():
>
>The dirfd( ) function may fail if:
>[EINVAL] The dirp argument do
Stefan Teleman writes:
> On Thursday 22 March 2007 18:23, Joerg Schilling wrote:
>
> > > The dirfd( ) function may fail if:
> > > [EINVAL] The dirp argument does not refer to a valid directory
> > > stream.
> >
> > May is not "must" ;-)
>
> It isn't "can't" or "shouldtn't" either.
Right, but tes
On Thursday 22 March 2007 18:23, Joerg Schilling wrote:
> > The dirfd( ) function may fail if:
> > [EINVAL] The dirp argument does not refer to a valid directory
> > stream.
>
> May is not "must" ;-)
It isn't "can't" or "shouldtn't" either.
--Stefan
--
Stefan Teleman 'Nobody E
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> And to try to answer my own question, Draft 2 says
> (about dirfd() among others):
>
> ...shall be declared as functions and may also be defined as macros. Function
> prototypes shall be provided.
>
> and specifically about dirfd():
>
> The dirfd(
And to try to answer my own question, Draft 2 says
(about dirfd() among others):
...shall be declared as functions and may also be defined as macros. Function
prototypes shall be provided.
and specifically about dirfd():
The dirfd( ) function may fail if:
[EINVAL] The dirp argument does not refe
Question in my mind would be whether any existing implementation
allows a NULL argument (and presumably returns -1 then), and also
whether there's enough known about the direction of the POSIX draft
to know whether it would allow that behavior.
This message posted from opensolaris.org
_
>Note that POSIX requires that if opendir() is based on file descriptors
>(doesn't necessarily have to be), the file descriptor would be closed
>on exec. Perhaps someone needs to get clarification whether the intent
>will be for the added dirfd() to also do that; if so, a simple implementation
>w
> I'm happy to submit this to b.o.o (I still giggle at
> that acronym!), if it's of value to everyone.
> I know that it would help me out, but I'm big enough
> to realise that point doesn't really count for much
> ;)
If it would help you out, it might help others out, provided it's
done consistent
Hi folks,
Thanks for all the feedback on this. I have to confess, the more complex
replies are a little above my understanding, so in the interests of concluding
this thread clearly - what is the verdict?
I think we've had 3 responses agreeing that it's probably a good thing, if for
no other r
>Either approach (opendir()/dirfd() or open()/fdopendir())
>might be handy on Solaris or anything else that has openat(),
>for use with multithreaded programs.
(To be honest, our next revision of rm will store both an fd and a DIR*;
with dirfd() it would need to only store the DIR *)
Casper
>
> A function like dirfd() is probably needed for
> completeness and
> compatibility, though I wonder what people are using
> it for
Supposedly to do an opendir() then convert the result to
something they could use with fchdir(), although it seems
to me that if one was always going to do bot
It would be good to capture this request using http://bugs.opensolaris.org/
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
I know for a fact that at least one function already in LSB and on the
POSIX draft update for inclusion has been accepted.
If the POSIX draft (sign up for the austin group mailing list at
https://www.opengroup.org/sophocles/create_user.tpl?name=austin-group-l
to get access), the LSB, and perhaps
23 matches
Mail list logo
