perl5
perl5 copied to clipboard
Signal readdir() errors by clearing/setting errno
At least for Linux, distinguishing an error from the end of the directory listing is done by setting errno to 0 and then calling readdir(). Errno will then be set in the case of an error.
https://linux.die.net/man/3/readdir
This adresses
https://github.com/Perl/perl5/issues/17907
but unfortunately, there are no tests to (re)produce the behaviour at all.
I don't think this is correct on systems where we use readdir_r(), which doesn't set errno according to https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
It probably means the readdir() macro we define needs to set it (and will probably need to be a function instead.)
Just some notes here, while I work on this:
This will likely need changing two macro stanzas we have in reentr.h that define readdir(). They are # ifdef HAS_READDIR_R and # ifdef HAS_READDIR64_R. My rough plan is to convert them to one macro that calls the function and returns the error code and a second macro that accesses the buffer. Those two macros are then used in the _readdir() function which is called from pp_readdir.
# ifdef HAS_READDIR_R
# if defined(PERL_REENTR_API) && (PERL_REENTR_API+0 == 1)
# undef readdir
# if !defined(readdir) && READDIR_R_PROTO == REENTRANT_PROTO_I_TSR
# define _readdir_r_buf (PL_reentrant_buffer->_readdir_ptr)
# define _readdir_r(a) (readdir_r(a, PL_reentrant_buffer->_readdir_struct, &_readdir_r_buf))
# define readdir(a) (_readdir_r(a) == 0 ? _readdir_buf : 0)
# endif
# if !defined(readdir) && READDIR_R_PROTO == REENTRANT_PROTO_I_TS
# define _readdir_r_buf (PL_reentrant_buffer->_readdir_struct)
# define _readdir_r(a) (readdir_r(a, PL_reentrant_buffer->_readdir_struct, &_readdir_r_buf))
# define readdir(a) (_readdir_r(a) == 0 ? _readdir_buf : 0)
# endif
# if defined(readdir)
# define PERL_REENTR_USING_READDIR_R
# endif
# endif
# endif /* HAS_READDIR_R */
reentr.h is generated from reentr.pl, so in the long run, the code needs to go there.
Perl does not seem to use readdir64 at all?
I'm not sure if the zoo of macros each calling each other is worth the bother, but I can't see a good way for a clear cut. Maybe changing the API around, from being readdir() compatible to being readdir_r() compatible, and aliasing readdir64_r and readdir_r makes the code less convoluted, but I'll only know that once I've done such a conversion.
@Corion we're still working on this?
I'm still unclear on the status of blead, and whether there is a Perl 5 or Perl 7, so I've not looked at it. I still intend to work on it, but it will take a bit more revamping of reentr.pl to generate the appropriate macro definition.
The plan is to bump blead to 7.1.0 in the next days.
On 7/31/20 12:42 AM, Nicolas R. wrote:
The plan is to bump blead to 7.1.0 in the next days.
In the meantime, blead is completely open. Changes to files written in perl must conform to modern standards, such as use strict; use warnings.
@Corion we're still working on this?
@toddr , @Corion can we get an update on the status of this ticket?
Thank you very much. Jim Keenan
Yes, I'm still working on this. I'll come in with a new round of review questions once I have a working prototype.
This is still on my plate but unlikely to land before end of March as I'm busy with other things...
@Corion how goes this?
I changed the title to that of the commit, which makes more sense, it was confusing me every time I saw it in the list of open PRs.
This is still on my plate but unlikely to land before end of March as I'm busy with other things...
@Corion, since there have been no code changes in this p.r. since February 2021, I would like to close this ticket and have you open a new one as needed.
This is still on my plate but unlikely to land before end of March as I'm busy with other things...
@Corion, since there have been no code changes in this p.r. since February 2021, I would like to close this ticket and have you open a new one as needed.
No updates since last September; closing.