ossp-pkg/uuid/uuid.c 1.41 -> 1.42
--- 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
|
|
