From e6739005830202de48080b28d51d1701a9bec0cd Mon Sep 17 00:00:00 2001 From: Jarkko Hietaniemi Date: Thu, 5 Apr 2001 23:11:23 +0000 Subject: Slight doc tweak. p4raw-id: //depot/perl@9582 --- pod/perlunicode.pod | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'pod') 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 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 pragma can always be used to force byte semantics in a particular lexical scope. See L. -- cgit v1.2.1