apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Olavi Niemitalo <...@iki.fi>
Subject wrong byte order in apr_uuid_get (or apr_uuid_format)
Date Thu, 22 Sep 2005 21:14:37 GMT
 * 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.

Mime
View raw message