ossp-pkg/uuid/uuid.c 1.28 -> 1.29
--- uuid.c 2004/01/15 16:22:09 1.28
+++ uuid.c 2004/01/15 17:24:56 1.29
@@ -444,34 +444,34 @@
* conflict between UUIDs generated by machines with and without network
* cards."
*
- * This clearly explains what the intention is. Unfortunately, it
- * explains it incorrectly how to achieve this. Because (see also
+ * This clearly explains the intention. Unfortunately, it incorrectly
+ * explains how to achieve it. Because (see also
* http://www.iana.org/assignments/ethernet-numbers and "Understanding
* Physical Addresses" in "Ethernet -- The Definitive Guide", p.43) it
* is the "LEAST significant bit of the first octet of the node ID" in a
* memory representation of a 48-bit MAC address. The reason is that it
* is the MOST significant bit only in IEEE 802.3 _transmission order_
- * of a MAC address. The memory order of an octet from a MAC address is
- * always with the bits from left/MSB/bit-7 to right/LSB/bit-0!
+ * of a MAC address. The bitwise memory order of a MAC address octet is
+ * always from left/MSB/bit-7 to right/LSB/bit-0!
*
* Unfortunately, even the reference code in
* "draft-leach-uuids-guids-01" incorrectly sets the multicast bit with
* an "OR 0x80" bit operation. This could be considered "standards
* compliant" (because the exact wording above is "with the most
- * significant bit"), but from the remaining explanation it becomes 100%
+ * significant bit"). However, from the remaining explanation it becomes 100%
* clear that the intention was different and the wording and code was
- * incorrect because the authors were unaware of this difference in bit
+ * incorrect. The authors were likely unaware of this difference in bit
* ordering between memory and wire transmission.
*
- * So, OSSP uuid does it the intended/correct way and generates a real
- * IEEE 802 multicast address, but with a compile-time option one can
- * nevertheless enforce the generation of incorrect addresses according
- * to the standards. For the decoding we always use the correct way, of
+ * By default, OSSP uuid works the intended/correct way and generates a real
+ * IEEE 802 multicast address. Nevertheless, a compile-time option exists
+ * for the generation of incorrect addresses according
+ * to the standards. For the decoding we always use the correct way of
* course.
*
- * Luckily, both DCE 1.1 and ISO/IEC 11578:1996 do not deal with the
- * situation of not available IEEE 802 addresses at all and so have
- * avoided to adopt this bug from the original draft and code ;-)
+ * Luckily, neither DCE 1.1 nor ISO/IEC 11578:1996 are affected by this problem.
+ * They disregard the topic of missing IEEE 802 addresses entirely, and thus
+ * avoid adopting this bug from the original draft and code ;-)
*/
/* encoding */
|
|
