httpd-2.0.53/srclib/apr-util/crypto/getuuid.c (APR-util 0.9.6) carries this comment:
* This attempts to generate V1 UUIDs according to the Internet Draft * located at http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt Section 3.5 of that draft states that each field of the string representation is printed with the most significant digit first. Here, a "field" is e.g. the 32-bit time_low. I made a program: #define _POSIX_SOURCE #include <stdio.h> #include <limits.h> #include <apr_uuid.h> int main(void) { for (int i = 0; i < 10; ++i) { apr_uuid_t uuid; apr_uuid_get(&uuid); char buffer[APR_UUID_FORMATTED_LENGTH + 1]; apr_uuid_format(buffer, &uuid); puts(buffer); } return 0; } The output from one run: ef3de68a-6201-0410-8b87-96b5f2334e11 6f3ee68a-6201-0410-8b87-96b5f2334e11 7a3ee68a-6201-0410-8b87-96b5f2334e11 843ee68a-6201-0410-8b87-96b5f2334e11 8e3ee68a-6201-0410-8b87-96b5f2334e11 973ee68a-6201-0410-8b87-96b5f2334e11 a13ee68a-6201-0410-8b87-96b5f2334e11 aa3ee68a-6201-0410-8b87-96b5f2334e11 b43ee68a-6201-0410-8b87-96b5f2334e11 bd3ee68a-6201-0410-8b87-96b5f2334e11 Note how only the first four digits have changed. These should be the most significant 16 bits of time_low. And in the second line, time_low appears to be *smaller* than in the first line, if read according to the draft. Indeed, apr_uuid_get puts the bytes in little-endian order: unsigned char *d = uuid->data; ... d[0] = (unsigned char)timestamp; d[1] = (unsigned char)(timestamp >> 8); d[2] = (unsigned char)(timestamp >> 16); d[3] = (unsigned char)(timestamp >> 24); and apr_uuid_format stores the characters in the same order as the bytes are in the array: const unsigned char *d = uuid->data; sprintf(buffer, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", d[0], d[1], d[2], d[3], d[4], d[5], d[6], d[7], d[8], d[9], d[10], d[11], d[12], d[13], d[14], d[15]); I initially noticed this when I was trying to make sense of the version bitfield of Subversion repository UUIDs.
pgpbTfG7RJopA.pgp
Description: PGP signature
