EBCDIC: disable also Unicode::Collate and

Unicode::Normalize for now.  Real users of
EBCDIC have to decide what they want.

p4raw-id: //depot/perl@14848

2 files changed, 23 insertions, 0 deletions

diff --git a/lib/Unicode/Collate.pm b/lib/Unicode/Collate.pm
index bd10fdd22f..8522a79f2c 100644
--- a/lib/Unicode/Collate.pm
+++ b/lib/Unicode/Collate.pm
@@ -1,5 +1,11 @@
 package Unicode::Collate;
 
+BEGIN {
+    if (ord("A") == 193) {
+	die "Unicode::Collate not ported to EBCDIC\n";
+    }
+}
+
 use 5.006;
 use strict;
 use warnings;
@@ -776,6 +782,16 @@ is primary equal to C<"m>E<252>C<ss">.
 
 None by default.
 
+=head2 TODO
+
+Unicode::Collate has not been ported to EBCDIC.  The code mostly would
+work just fine but a decision needs to be made: how the module should
+work in EBCDIC?  Should the low 256 characters be understood as
+Unicode or as EBCDIC code points?  Should one be chosen or should
+there be a way to do either?  Or should such translation be left
+outside the module for the user to do, for example by using
+Encode::from_to()?
+
 =head2 CAVEAT
 
 Use of the C<normalization> parameter requires
diff --git a/lib/Unicode/Collate/t/test.t b/lib/Unicode/Collate/t/test.t
index d9ee1fe2e3..57e20579cb 100644
--- a/lib/Unicode/Collate/t/test.t
+++ b/lib/Unicode/Collate/t/test.t
@@ -3,6 +3,13 @@
 
 #########################
 
+BEGIN {
+    if (ord("A") == 193) {
+	print "1..0 # Unicode::Collate not ported to EBCDIC\n";
+	exit 0;
+    }
+}
+
 use Test;
 BEGIN { plan tests => 54 };
 use Unicode::Collate;