apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: wrong byte order in apr_uuid_get (or apr_uuid_format)
Date Fri, 23 Sep 2005 16:54:20 GMT
This undoubtedly breaks any cache of uuid values.

I don't mind doing this in the APR 1.x->2.0 transition, but it can't
be applied any early without causing significant disruption for users.

Please prepare a patch with the old behavior and new behavior blocked

#ifdev APR_2_0_BUMP
... [future behavior]
#else
... [old behavior]
#endif

and modify the .h file with an @bug entry explaining the issue, in the
function's doxygen grammer.


Kalle Olavi Niemitalo wrote:
> 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.


Mime
View raw message