about summary refs log tree commit diff
path: root/manual/charset.texi
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2007-07-31 13:33:18 +0000
committerJakub Jelinek <jakub@redhat.com>2007-07-31 13:33:18 +0000
commit32c075e1f01849e161724bbd400ba77244e482cc (patch)
tree5f083a3f352104f32bb6c902d57fa3f294bd8d4d /manual/charset.texi
parentd6220e9ee38c1c9285221b023346201ec5f511b3 (diff)
downloadglibc-32c075e1f01849e161724bbd400ba77244e482cc.tar.gz
glibc-32c075e1f01849e161724bbd400ba77244e482cc.tar.xz
glibc-32c075e1f01849e161724bbd400ba77244e482cc.zip
.
Diffstat (limited to 'manual/charset.texi')
-rw-r--r--manual/charset.texi6
1 files changed, 3 insertions, 3 deletions
diff --git a/manual/charset.texi b/manual/charset.texi
index 8b2c09ca79..5063246d61 100644
--- a/manual/charset.texi
+++ b/manual/charset.texi
@@ -207,7 +207,7 @@ and transmittal.  Because each single wide character consists of more
 than one byte, they are effected by byte-ordering.  Thus, machines with
 different endianesses would see different values when accessing the same
 data.  This byte ordering concern also applies for communication protocols
-that are all byte-based and therefore require that the sender has to
+that are all byte-based and, thereforet require that the sender has to
 decide about splitting the wide character in bytes.  A last (but not least
 important) point is that wide characters often require more storage space
 than a customized byte-oriented character set.
@@ -737,7 +737,7 @@ the return value is @math{0}.  If the next @var{n} bytes form a valid
 multibyte character, the number of bytes belonging to this multibyte
 character byte sequence is returned.
 
-If the first @var{n} bytes possibly form a valid multibyte
+If the the first @var{n} bytes possibly form a valid multibyte
 character but the character is incomplete, the return value is
 @code{(size_t) -2}.  Otherwise the multibyte character sequence is invalid
 and the return value is @code{(size_t) -1}.
@@ -2231,7 +2231,7 @@ ordering of the processor (or at least the running process) is not the
 same as the one required for UCS-4.  This is done for performance reasons
 as one does not want to perform unnecessary byte-swapping operations if
 one is not interested in actually seeing the result in UCS-4.  To avoid
-trouble with endianness, the internal representation consistently is named
+trouble with endianess, the internal representation consistently is named
 @code{INTERNAL} even on big-endian systems where the representations are
 identical.