Acknowledge some known tie bugs.

p4raw-id: //depot/perl@21042

1 files changed, 10 insertions, 6 deletions

diff --git a/pod/perltie.pod b/pod/perltie.pod
index 8f3a6774ae..7b8d4970ad 100644
--- a/pod/perltie.pod
+++ b/pod/perltie.pod
@@ -1072,6 +1072,14 @@ modules L<Tie::Scalar>, L<Tie::Array>, L<Tie::Hash>, or L<Tie::Handle>.
 
 =head1 BUGS
 
+The bucket usage information provided by C<scalar(%hash)> is not
+available.  What this means is that using %tied_hash in boolean
+context doesn't work right (currently this always tests false,
+regardless of whether the hash is empty or hash elements).
+
+Localizing tied arrays or hashes does not work.  After exiting the
+scope the arrays or the hashes are not restored.
+
 You cannot easily tie a multilevel data structure (such as a hash of
 hashes) to a dbm file.  The first problem is that all but GDBM and
 Berkeley DB have size limitations, but beyond that, you also have problems
@@ -1083,12 +1091,8 @@ source code to MLDBM.
 Tied filehandles are still incomplete.  sysopen(), truncate(),
 flock(), fcntl(), stat() and -X can't currently be trapped.
 
-The bucket usage information provided by C<scalar(%hash)> is not
-available.  If C<%hash> is tied, this will currently result in a
-fatal error.
-
-Counting the number of entries in a hash via C<scalar(keys(%hash))> or
-C<scalar(values(%hash)>) is inefficient since it needs to iterate
+Counting the number of entries in a hash via C<scalar(keys(%hash))>
+or C<scalar(values(%hash)>) is inefficient since it needs to iterate
 through all the entries with FIRSTKEY/NEXTKEY.
 
 =head1 AUTHOR