Slight doc tweak.

p4raw-id: //depot/perl@9582

1 files changed, 7 insertions, 7 deletions

diff --git a/pod/perlunicode.pod b/pod/perlunicode.pod
index bb3ce2b87d..5b8d5be06c 100644
--- a/pod/perlunicode.pod
+++ b/pod/perlunicode.pod
@@ -32,12 +32,12 @@ in an particular encoding.
 
 =item Regular Expressions
 
-The regular expression compiler does now attempt to produce polymorphic
-opcodes.  That is the pattern should now adapt to the data and
-automaticaly switch to the Unicode character scheme when presented with Unicode data,
-or a traditional byte scheme when presented with byte data.
-The implementation is still new and (particularly on EBCDIC platforms) may
-need further work.
+The regular expression compiler does now attempt to produce
+polymorphic opcodes.  That is the pattern should now adapt to the data
+and automatically switch to the Unicode character scheme when presented
+with Unicode data, or a traditional byte scheme when presented with
+byte data.  The implementation is still new and (particularly on
+EBCDIC platforms) may need further work.
 
 =item C<use utf8> still needed to enable a few features
 
@@ -78,7 +78,7 @@ or from literals and constants in the source text.
 If the C<-C> command line switch is used, (or the ${^WIDE_SYSTEM_CALLS}
 global flag is set to C<1>), all system calls will use the
 corresponding wide character APIs.  This is currently only implemented
-on Windows.
+on Windows since UNIXes lack API standard on this area.
 
 Regardless of the above, the C<bytes> pragma can always be used to force
 byte semantics in a particular lexical scope.  See L<bytes>.