[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 = fdopendir(dup(dfd));
[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 chdir(..) later.
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, as a macro,
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(), although it
[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 need to
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, that
[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 = fdopendir(dup(dfd));
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
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
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 the
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 the
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
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
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( ) function
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 Expects the
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 testing for NULL is still
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
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 consistently
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
would
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 both,
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
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
22 matches
Mail list logo
