=head1 DESCRIPTION
-This document describes differences between the 5.9.0 release and
-
the 5.9.1 release. See L<perl590delta> for the differences between
+This document describes differences between the 5.9.0 and the 5.9.1
+
development releases. See L<perl590delta> for the differences between
5.8.0 and 5.9.0.
=head1 Incompatible Changes
The lvalues returned by the three argument form of substr() used to be a
"fixed length window" on the original string. In some cases this could
cause surprising action at distance or other undefined behaviour. Now the
-length of the window adjusts iself to the length of the string assigned to
+length of the window adjusts itself to the length of the string assigned to
it.
=head2 The C<:unique> attribute is only meaningful for globals
C<case $variable $define)> branch. This change should only affect platform
maintainers writing configuration hints files.
-The portability and clealiness of the Win32 makefiles has been improved.
+The portability and cleanliness of the Win32 makefiles has been improved.
=head1 Known Problems
When configured with long doubles, perl may fail tests 224-236 in
F<t/op/pow.t> on the same platform.
+For threaded builds, F<ext/threads/shared/t/wait.t> has been reported to
+fail some tests on HP-UX 10.20.
+
=head1 To-do for perl 5.10.0
This is a non-exhaustive, non-ordered, non-contractual and non-definitive
Clean up and finish support for assertions. See L<assertions>.
Reimplement the mechanism of lexical pragmas to be more extensible. Fix
-current pragmas that don't work well with lexical scopes or in
-eval(STRING) (C<sort>, C<re> for example). MJD has ideas on this.
+current pragmas that don't work well (or at all) with lexical scopes or in
+run-time eval(STRING) (C<sort>, C<re>, C<encoding> for example). MJD has a
+preliminary patch that implements this.
Fix (or rewrite) the implementation of the C</(?{...})/> closures.
Conversions from byte strings to UTF-8 currently map high bit characters
to Unicode without translation (or, depending on how you look at it, by
-implicitly assuming the byte strings are in Latin-1). This is wrong,
-because perl assumes the C locale by default. Thus upgrading a string to
-UTF-8 (esp. in place) may change the meaning of its contents regarding
-character classes, case mapping, etc. Try to find a way to fix it without
-breaking all the legacy code out there (and without making the life of the
-XS coders miserable.)
+implicitly assuming that the byte strings are in Latin-1). As perl assumes
+the C locale by default, upgrading a string to UTF-8 may change the
+meaning of its contents regarding character classes, case mapping, etc.
+This should probably emit a warning (at least).
Introduce a new special block, UNITCHECK, which is run at the end of a
compilation unit (module, file, eval(STRING) block). This will correspond to
Make threads more robust.
-Make C<no 6> and C<no v6> work.
+Make C<no 6> and C<no v6> work (opposite of C<use 5.005>, etc.).
A test suite for the B module would be nice.
If you find what you think is a bug, you might check the articles
recently posted to the comp.lang.perl.misc newsgroup and the perl
bug database at http://bugs.perl.org/ . There may also be
-information at http://www.perl.com/ , the Perl Home Page.
+information at http://www.perl.org/ , the Perl Home Page.
If you believe you have an unreported bug, please run the B<perlbug>
program included with your release. Be sure to trim your bug down
https://perl5.git.perl.org / perl5.git / blobdiff