Index: ossp-pkg/uuid/uuid.c
RCS File: /v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v
rcsdiff -q -kk '-r1.41' '-r1.42' -u '/v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v' 2>/dev/null
--- uuid.c	2004/01/19 12:15:05	1.41
+++ uuid.c	2004/01/19 13:55:18	1.42
@@ -97,21 +97,21 @@
    and code ;-)
 
    It seems that this standards bug arises from a false interpretation,
-   as the multicast bit is actually is the *MOST* significant bit in
-   IEEE 802.3 (Ethernet) _transmission order_ of an IEEE 802 MAC address.
-   The authors were likely not aware that the bitwise order of an octet
-   from a MAC address memory and hexadecimal string representation is
-   still always from left (MSB, bit 7) to right (LSB, bit 0).
+   as the multicast bit is actually the *MOST* significant bit in IEEE
+   802.3 (Ethernet) _transmission order_ of an IEEE 802 MAC address. The
+   authors were likely not aware that the bitwise order of an octet from
+   a MAC address memory and hexadecimal string representation is still
+   always from left (MSB, bit 7) to right (LSB, bit 0).
 
    For more information, see "Understanding Physical Addresses" in
    "Ethernet -- The Definitive Guide", p.43, and the section "ETHERNET
    MULTICAST ADDRESSES" in http://www.iana.org/assignments/ethernet-numbers.
 
-   At OSSP, we do it the intended/correct way and generate a real IEEE 802
-   multicast address. Those wanting to encode broken IEEE 802 MAC addresses
-   (as specified) can nevertheless use a brain dead compile-time option
-   to switch off the correct behavior. When decoding we always use the
-   correct behavior of course. */
+   At OSSP, we do it the intended/correct way and generate a real
+   IEEE 802 multicast address. Those wanting to encode broken IEEE
+   802 MAC addresses (as specified) can nevertheless use a brain dead
+   compile-time option to switch off the correct behavior. When decoding
+   we always use the correct behavior of course. */
 
 /* encoding */
 #ifdef WITH_RFC2518