From 140cb37ed79835bf0c0cde1ebe5ce5eceaa7b04b Mon Sep 17 00:00:00 2001 From: Vadim Konovalov Date: Mon, 20 Sep 1999 13:43:49 +0400 Subject: [PATCH] Fix a bug in the description of endianness. Reported in From: "Konovalov, Vadim" To: perl5-porters@perl.org Subject: BUG: perldoc -f pack Message-ID: <402099F49BEED211999700805FC7359F20D3F5@ru0028exch01.spb.lucent.com> p4raw-id: //depot/cfgperl@4202 --- pod/perlfunc.pod | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 995a671..9968ee7 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -2869,7 +2869,7 @@ not support long longs.) The integer formats C<"s">, C<"S">, C<"i">, C<"I">, C<"l">, and C<"L"> are inherently non-portable between processors and operating systems because they obey the native byteorder and endianness. For example a -4-byte integer 0x87654321 (2271560481 decimal) be ordered natively +4-byte integer 0x12345678 (305419896 decimal) be ordered natively (arranged in and handled by the CPU registers) into bytes as 0x12 0x34 0x56 0x78 # little-endian @@ -2885,7 +2885,7 @@ the classic "Gulliver's Travels" (via the paper "On Holy Wars and a Plea for Peace" by Danny Cohen, USC/ISI IEN 137, April 1, 1980) and the egg-eating habits of the Lilliputians. -Some systems may even have weird byte orders such as +Some systems may have even weirder byte orders such as 0x56 0x78 0x12 0x34 0x34 0x12 0x78 0x56 -- 2.7.4