Perl 5.9.4 is out

[Rafael Garcia-Suarez]

Perl 5.9.4, the latest development release of Perl 5, is currently
propagating to CPAN. Here are the administrative details:

file: $CPAN/authors/id/R/RG/RGARCIA/perl-5.9.4.tar.gz
size: 14298383 bytes
md5: a98e0af9f221362227c813bff69e4e91

For what's new, see the perl594delta man page.
For what's left for 5.10.0, see the perltodo man page.
Many thanks to all those who have contributed.

[Benjamin Holzman]

I note that this still contains bug #26136 (localtime(3) calls tzset(3),
but localtime_r(3) may not). Is there a problem with the patch that was
submitted?

Thanks,

Benjamin Holzman

[SADAHIRO Tomoyuki]

On Thu, 17 Aug 2006 07:04:57 -0400, "Holzman, Benjamin" wrote

> I note that this still contains bug #26136 (localtime(3) calls tzset(3),
> but localtime_r(3) may not). Is there a problem with the patch that was
> submitted?
>
> Thanks,
>
> Benjamin Holzman

Please make sure that you cover _all_ perl platforms,
or make sure that the test is skipped on the platforms
you does not cover. (In other words, make sure that
the test is performed just on the platforms you cover.)

op/tiehandle............................................ok
op/time.................................................FAILED test 5
Failed 1/8 tests, 87.50% okay
op/tr...................................................ok
op/undef................................................ok

I tried 26136.patch in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-07/msg00661.html

Regards,
SADAHIRO Tomoyuki

[Benjamin Holzman]

I would think that the test should pass on all platforms. Do you
disagree? What platform did you get the failure on? Is Configure
setting d_localtime_r_needs_tzset? If not, does it work if you force
it?

Thanks,

Ben

[SADAHIRO Tomoyuki]

On Thu, 17 Aug 2006 10:56:29 -0400, "Holzman, Benjamin" wrote

> I would think that the test should pass on all platforms. Do you
> disagree? What platform did you get the failure on? Is Configure
> setting d_localtime_r_needs_tzset? If not, does it work if you force
> it?

What I disagree is the test failure.
According to the comment in ext/POSIX/t/time.t, some platforms don't
have tzset() in C. I think your test to ensure localtime() in perl
respects changing TZ should fail on such platforms, where localtime()
in C wouldn't respect TZ. (If I understand it correctly, TZ is not
from ANSI C; should POSIX be a requirement for perl?)

P.S. We have POSIX::tzset. You can call it yourself in perl space
if necessary, can't you?

Regards,
SADAHIRO Tomoyuki

[Benjamin Holzman]

> What I disagree is the test failure.
> According to the comment in ext/POSIX/t/time.t, some platforms don't
> have tzset() in C. I think your test to ensure localtime() in perl
> respects changing TZ should fail on such platforms, where localtime()
> in C wouldn't respect TZ. (If I understand it correctly, TZ is not
> from ANSI C; should POSIX be a requirement for perl?)

Ok, I guess that makes sense. I actually didn't realize that TZ wasn't
in ANSI C. I will see if I can find a reliable way to determine if
localtime() in C *should* respect TZ and only run the test in that case.
Obviously if localtime shouldn't respect TZ, we shouldn't bother trying
to call tzset before localtime_r either.

> P.S. We have POSIX::tzset. You can call it yourself in perl space
> if necessary, can't you?

Sure, I could, but I'm trying to prevent other people from running into
this problem. We've already applied this patch to our local perl. The
worst part about it is that threaded perl behaves differently from
non-threaded perl. Also note that this problem is not specific to
redhat or even linux; it affects all platforms using glibc.

Thanks for your input,

Benjamin Holzman