boostorg / uuid

Boost.org uuid module

Boost.Uuid

Boost.Uuid, part of Boost C++ Libraries, provides a C++ implementation of Universally Unique Identifiers (UUID) as described in RFC 4122 and RFC 9562.

See the documentation for more information.

License

Distributed under the Boost Software License, Version 1.0.

Properties

• C++11 (since Boost 1.86.0)
• Header-only

Current Status

Branch	Github Actions	Appveyor	Dependencies	Documentation	Test Matrix
master
develop

More Information

• Ask questions
• Report bugs: Be sure to mention Boost version, platform and compiler you're using. A small compilable code sample to reproduce the problem is always good as well.
• Submit your patches as pull requests against the develop branch. Note that by submitting patches you agree to license your modifications under the Boost Software License, Version 1.0.
• Discussions about the library are held on the Boost developers mailing list. Be sure to read the discussion policy before posting and add the [uuid] tag at the beginning of the subject line.

Code Example - UUID Generation

//  mkuuid.cpp example

#include <boost/uuid.hpp>
#include <iostream>

int main()
{
    boost::uuids::random_generator gen;
    std::cout << gen() << std::endl;
}

$ clang++ -Wall -Wextra -std=c++11 -O2 mkuuid.cpp -o mkuuid
$ ./mkuuid
2c186eb0-89cf-4a3c-9b97-86db1670d5f4
$ ./mkuuid
a9d3fbb9-0383-4389-a8a8-61f6629f90b6

uuid's Issues

x86 optimized operators are slower than generic version

https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/detail/uuid_x86.ipp

All these custom 128-bit loads are unnecessary in x86 version of operators.

Just use memcmp like in generic version.

generic_compare(uuid const&, uuid const&):          # @generic_compare(uuid const&, uuid const&)
        vmovdqu xmm0, xmmword ptr [rdi]
        vpxor   xmm0, xmm0, xmmword ptr [rsi]
        vptest  xmm0, xmm0
        sete    al
        ret
x86_compare(uuid const&, uuid const&):              # @x86_compare(uuid const&, uuid const&)
        vlddqu  xmm0, xmmword ptr [rdi]
        vlddqu  xmm1, xmmword ptr [rsi]
        vxorpd  xmm0, xmm1, xmm0
        vptest  xmm0, xmm0
        sete    al
        ret

gcc trunk and clang.

https://godbolt.org/z/b3jnaK1v7

gcc 12.2, produces suboptimal code for memcmp, creating 64-bit loads. But newer gcc works fine.

In the future it should be fine to just remove x86 optimized version, and use memcmp. But for now, combing a load and xor would be the best.

Can generator is shared by multiple threads without locks?

Background

I'm using Boost.Uuid 1.76.0

I wrote the code as follows:
The random_generator instance gen as static variable.

#include <boost/uuid/uuid.hpp>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <iostream>

inline std::string create_uuid_string() {
    static auto gen = boost::uuids::random_generator();
    return boost::uuids::to_string(gen());
}

int main() {
    std::cout << create_uuid_string() << std::endl;
    std::cout << create_uuid_string() << std::endl;
}

https://wandbox.org/permlink/0sORjrX3QXtsO8zb

Question1

According to the following document, I guess that calling create_uuid_string() from multiple threads without locks are not thread-safe. Because the functioncreate_uuid_string() calls gen() , operator()() of random_generator

uuid/doc/uuid.html

Lines 858 to 859 in eaa4be7

	<p>All functions are re-entrant. Classes are as thread-safe as an int. That is an
	instance can not be shared between threads without proper synchronization.

Is that right?

Question2

If the Question1 is NOT thread-safe, I come up with two solution.
One is introducing lock to access gen(). But it would introduce thread serialization point.
It could be performance penalty.

The other is removing static from gen declaration. That means creating gen for each create_uuid_string().
It doesn't require locks but each time creates gen.
It could be performance penalty.

inline std::string create_uuid_string() {
    auto gen = boost::uuids::random_generator();
    return boost::uuids::to_string(gen());
}

Which approach is better performance? Or is there other better approach?

Release Notes for Boost.Uuid release 1.67.0

• [phrase library..[@/libs/uuid/ Uuid]:]
  • Optimized random_generator to use OS-provided entropy directly, thus avoiding the initialization cost of a PRNG.
  • Provided random_generator_mt19937 for bulk UUID generation (more expensive to initialize the PRNG, but may be faster overall if generating lots of UUIDs).
  • Handle entropy acquisition errors instead of ignoring them.
  • Use getentropy() or arc4random() instead of /dev/urandom on platforms that provide it.
  • Support for CloudABI
  • Support for Windows UWP (non-desktop partitions) through BCrypt ([github uuid 24])

threeway comparision support

it would be great if operator <=> would be supported

CI: add bigendian test (and coverage report)

In the cutover from travis+appveyor to gha, some things got left off to make forward progress. This is one of them.

seed_rng.hpp does not compile for Windows UWP apps

These Win32 functions are not allowed to be used with UWP apps:

CryptAcquireContext
CryptReleaseContext
CryptGenRandom

see here
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379886(v=vs.85).aspx

Some replacement functions should be used instead.

I have tried to compile using this Windows SDK/ Target Platform Version: 10.0.15063.0

Add namespace constants from appendix C of RFC 4122

https://tools.ietf.org/html/rfc4122#appendix-C

There is a TODO in the current name_generator.hpp header to this effect.

Memory sanitizer warning on boost::uuids::to_string() call

Good afternoon!

I have built a program that uses uuid library under msan and surprisingly got a warning. Here is a minimized example:

#include <iostream>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>

int main() {
  boost::uuids::random_generator generator;
  auto uuid = generator();
  auto string_uuid = boost::uuids::to_string(uuid);
  std::cout << string_uuid << std::endl;

  return 0;
}

The output is:

==10428==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4a6956 in boost::uuids::detail::to_char(unsigned long) /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:132:9
    #1 0x498877 in boost::uuids::to_string(boost::uuids::uuid const&) /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:157:19
    #2 0x497c1e in main /home/luckychess/src/uuid_test/main.cpp:8:22
    #3 0x7f1ee403109a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
    #4 0x41d449 in _start (/home/luckychess/src/uuid_test/build/uuid_test+0x41d449)

  Uninitialized value was stored to memory at
    #0 0x4a68b1 in boost::uuids::detail::to_char(unsigned long) /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:131
    #1 0x498877 in boost::uuids::to_string(boost::uuids::uuid const&) /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:157:19
    #2 0x497c1e in main /home/luckychess/src/uuid_test/main.cpp:8:22
    #3 0x7f1ee403109a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16

  Uninitialized value was stored to memory at
    #0 0x498801 in boost::uuids::to_string(boost::uuids::uuid const&) /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:156:22
    #1 0x497c1e in main /home/luckychess/src/uuid_test/main.cpp:8:22
    #2 0x7f1ee403109a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16

  Uninitialized value was stored to memory at
    #0 0x497b48 in main /home/luckychess/src/uuid_test/main.cpp:7:15
    #1 0x7f1ee403109a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16

  Uninitialized value was stored to memory at
    #0 0x422f8b in __msan_memcpy (/home/luckychess/src/uuid_test/build/uuid_test+0x422f8b)
    #1 0x498031 in boost::uuids::random_generator_pure::operator()() /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/random_generator.hpp:212:16
    #2 0x497ac3 in main /home/luckychess/src/uuid_test/main.cpp:7:15
    #3 0x7f1ee403109a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16

  Uninitialized value was created by an allocation of 'result' in the stack frame of function '_ZN5boost5uuids21random_generator_pureclEv'
    #0 0x497dd0 in boost::uuids::random_generator_pure::operator()() /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/random_generator.hpp:209

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/luckychess/src/boost/boost_1_70_0_msan/include/boost/uuid/uuid_io.hpp:132:9 in boost::uuids::detail::to_char(unsigned long)
Exiting

It may looks like uuid variable is not initialized properly but I did a check under debugger and it shows clear that all bytes in underlying uuid array are initialized so I'm confused. Also if I try to use std::cout << uuid << std::endl; (without to_string call) everything is fine.

To reproduce this you need to build an instrumented version of libc++ and link this program against it. I used a manual from here.

Any ideas?

Constructing UUIDs from 2 64 bit integers

As opened question in stackoverflow suggests it is occasionally highly useful to create UUIDs from a pair of 64 bit integers.

Java provides the mechanism to do so:

UUID test_uuid(long1, long2);

It would be very helpful to be able to do the same with boost::uuid

uuid_io (operator>>) needs to be as strict as string_generator

In #17 changes were made to strengthen the string generator's parsing rules. These rules were not applied, nor were tests added to the uuid_io implementation. This was discovered through integration with codecov.io, which pointed out incomplete code coverage in uuid_io.

unresolved external symbol BCrypt*** after upgrading to boost 1.67

After upgrading boost from 1.66 to 1.67 my code

auto id = boost::lexical_cast<std::string>(boost::uuids::random_generator()());

doesn't compile anymore.

error LNK2019: unresolved external symbol BCryptCloseAlgorithmProvider referenced in function "public: __cdecl boost::uuids::random_generator_pure::~random_generator_pure(void)" (??1random_generator_pure@uuids@boost@@QEAA@XZ)
error LNK2001: unresolved external symbol BCryptCloseAlgorithmProvider
error LNK2019: unresolved external symbol BCryptGenRandom referenced in function "public: struct boost::uuids::uuid __cdecl boost::uuids::random_generator_pure::operator()(void)" (??Rrandom_generator_pure@uuids@boost@@QEAA?AUuuid@12@XZ)
error LNK2001: unresolved external symbol BCryptGenRandom
error LNK2019: unresolved external symbol BCryptOpenAlgorithmProvider referenced in function "public: __cdecl boost::uuids::random_generator_pure::random_generator_pure(void)" (??0random_generator_pure@uuids@boost@@QEAA@XZ)
error LNK2001: unresolved external symbol BCryptOpenAlgorithmProvider
fatal error LNK1120: 3 unresolved externals
build stopped: subcommand failed.

In my header I'm including

#include <boost/format.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/uuid/uuid.hpp>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <boost/algorithm/string/predicate.hpp>

Installed boost via vcpkg, building using ninja/msbuild'17
using boost with cmake:

find_package(Boost COMPONENTS system
                          serialization
                          thread
                          date_time
                          regex
                          random
                          program_options
                          filesystem      REQUIRED)

Do I have to link against additional libraries?

Pinging @jeking3 because https://www.boost.org/doc/libs/1_67_0/boost/uuid/detail/random_provider_bcrypt.ipp looks somewhat related.

Align `uuid` to 16 bytes

I propose adding BOOST_ALIGNMENT(16) attribute to the uuid type definition.

Aligning uuid type to 16 bytes can be beneficial for SIMD algorithms (e.g. uuid comparison operators), even on modern CPUs. Accessing vectors that are split across cache line or page boundaries can incur a significant performance penalty. Without aligning the uuid type this can happen in non-obvious and difficult to rectify cases. For example, in a flat_map<uuid, object*> with 64-bit pointers, every other element of such flat map will have a misaligned uuid key, and the lookup function will likely be affected by the aforementioned penalty.

Adding alignment to uuid will result in added padding in users' structs where previously UUIDs were unaligned. Where such increase in size is important, it is often easy to work around by reordering data members to place more data in the padding. However, this would be an ABI breaking change, so it should be mentioned in the release notes.

name_generator uses a fixed, insecure hash algorithm (SHA1)

Earlier this year Google announced that they had produced the first SHA1 collision:

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

The boost::uuid library maintains a SHA1 implementation today for purposes of the name_generator, which takes any arbitrary sized set of data and generates a UUID from it. The library is hardcoded to use the SHA1 hash algorithm today.

The proposed improvement here is to make the hash algorithm configurable. A new HashingProvider concept would be introduced (or at least discussed) and/or a pure virtual base specifying the required methods an algorithm would need to implement (process_byte, process_bytes, get_digest); modify name_generator to be a template class where the hash algorithm is supplied as a template parameter, and checked to be a base of this virtual class at compile time such that a usable error message would occur.

To maintain backwards compatibility a default template parameter leveraging the existing SHA1 hash algorithm would be introduced, however it would be deprecated, and eventually the default would be removed thus forcing all use of name_generator to specify the hash algorithm as a mechanism to gently move them away from the less secure SHA1 to something else.

It may also be useful to move hashing to its own library where the HashingProvider concept could live, similar to how the UniformRandomNumberGenerator concept lives in boost::random.

constexpr uuid from string

Hi,
while searching for constexpr GUID from string generators, I found https://gist.github.com/AlexBAV/b58e92d7632bae5d6f5947be455f796f
which inspired me to generate a C++11 consexpr version plus boost-uuid generators.
If you're interested, please have a look at https://github.com/tobias-loew/constexpr-GUID-cpp-11

Tobias

Replace boost::mpl with boost::mp11

If possible please replace boost::mpl with boost::mp11.

time_generator - any opinions about adding it?

Hi,

I'm in some need for a time generator which our app uses to identify unique log elements streamed to various interested users. I'm no expert on UUIDs, but it seems to be a popular data element. The inherent order provided by time is used to organize the data downstream.

I'm just curious if there is a reason I am missing.

Cheers,
Jeff

Sign conversion error in uuid_clock.hpp

I got this error. It's causing Unordered tests to fail that weren't previously failing.

clang-linux.compile.c++ bin.v2/libs/unordered/test/visualization_tests.test/clang-linux-12/debug/x86_64/address-sanitizer-norecover/cxxstd-17-iso/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/visualization_tests.o
In file included from libs/unordered/test/debuggability/visualization_tests.cpp:29:
In file included from ./boost/uuid/random_generator.hpp:10:
In file included from ./boost/uuid/basic_random_generator.hpp:10:
In file included from ./boost/uuid/uuid.hpp:9:
./boost/uuid/uuid_clock.hpp:66:34: error: implicit conversion changes signedness: 'std::chrono::duration<long, std::ratio<1, 10000000>>::rep' (aka 'long') to 'std::uint64_t' (aka 'unsigned long') [-Werror,-Wsign-conversion]
    return tp.time_since_epoch().count();
    ~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
1 error generated.

I see a discrepancy in the uuid_clock class between int64_t and uint64_t. Not sure if one of these type should be changed to be the other one, or if static_cast is needed.

using rep = std::int64_t;
...
static time_point from_timestamp( std::uint64_t timestamp ) noexcept;
static std::uint64_t to_timestamp( time_point const& tp ) noexcept;

To reproduce it:

clang++ -Werror -Wsign-conversion path/to/boost/uuid/uuid_clock.hpp

unresolved external symbol BCrypt*** with ninja and clang-cl

Hi,

today I have prepared upgarde boost to 1.68 and I can't compile my project. I have prepared test program to reproduce issue:

CMakeLists.txt:

cmake_minimum_required(VERSION 3.10)
project("only4test" CXX)

find_package(Boost 1.6 REQUIRED)

add_executable(only4test
  main.cpp
  )

target_compile_options(only4test
  PRIVATE /W4)

target_link_libraries(only4test
  PRIVATE Boost::boost
  )

main.cpp

#include <iostream>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>

using namespace std;

int main()
{
    cout << boost::uuids::to_string(boost::uuids::random_generator()()) << '\n';
}

When it is compile with msvc it works, however when I change compiler to clang-cl the bcrypt library is not automaticly linked.

Msvc compilation:

cmake -G "Visual Studio 15 2017 Win64" .. -DBOOST_ROOT=%SRC%/boost_1_68_0
cmake --build .
Build succeeded.
    0 Warning(s)
    0 Error(s)

Clang compilation:

cmake -G "Ninja" .. -DBOOST_ROOT=%SRC%/boost_1_68_0/ -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_C_COMPILER=clang-cl
cmake --build .
main.cpp.obj : error LNK2019: unresolved external symbol BCryptOpenAlgorithmProvider referenced in function "public: __cdecl boost::uuids::detail::random_provider_base::random_provider_base(void)" (??0random_provider_base@detail@uuids@boost@@QEAA@XZ)
main.cpp.obj : error LNK2019: unresolved external symbol BCryptGenRandom referenced in function "public: void __cdecl boost::uuids::detail::random_provider_base::get_random_bytes(void *,unsigned __int64)" (?get_random_bytes@random_provider_base@detail@uuids@boost@@QEAAXPEAX_K@Z)
main.cpp.obj : error LNK2019: unresolved external symbol BCryptCloseAlgorithmProvider referenced in function "private: void __cdecl boost::uuids::detail::random_provider_base::destroy(void)" (?destroy@random_provider_base@detail@uuids@boost@@AEAAXXZ)
only4test.exe : fatal error LNK1120: 3 unresolved externals
ninja: build stopped: subcommand failed.

Did I need some additional flag to have auto link worked?

random_provider_base::get_random_bytes throws entropy_error when SYS_getrandom is not available

If you are on a system that does not have a recent glibc, you end up not having getrandom. In this case, random_provider_base::get_random_bytes calls get_random, which in turn calls ::syscall(SYS_getrandom, buf, size, flags). If your Linux version is older than 3.17 (where SYS_getrandom appeared) and assuming SYS_getrandom is not backported to your kernel, the call to ::syscall(SYS_getrandom, buf, size, flags) returns an error. Unfortunately, this results in throwing an entropy_error("getrandom"). This is a bit confusing, as the real problem is that no implementation of getrandom was found. It is a different issue to not have enough entropy. It would be preferable to throw a more appropriate exception here.

test_name_generator failed on big endian target

Test log:
../libs/uuid/test/test_name_generator.cpp(94): test 'md == correct_md5' failed in function 'int main(int, char**)': '06205cec-255b-300e-a8bc-a8605ab8244e' != 'ec5c2006-0e00-3b25-a0a8-bce84e24b85a'
1 error detected.

Potential solution:
Update boost/uuid/detail/md5.hpp with followings:

1. Add the following code:
   #if defined(i386) || defined(x86_64) || defined(vax)
   #define BOOST_UUID_DETAIL_MD5_OUT_NEW(dst, src)
   (dst)[0] = (unsigned char)(src);
   (dst)[1] = (unsigned char)((src) >> 8);
   (dst)[2] = (unsigned char)((src) >> 16);
   (dst)[3] = (unsigned char)((src) >> 24);
   #else
   #define BOOST_UUID_DETAIL_MD5_OUT_NEW(dst, src)
   (dst)[0] = (unsigned char)((src) >> 24);
   (dst)[1] = (unsigned char)((src) >> 16);
   (dst)[2] = (unsigned char)((src) >> 8);
   (dst)[3] = (unsigned char)(src);
   #endif
2. Update the following code in MD5_Final() to use the new macro:
   From:
   BOOST_UUID_DETAIL_MD5_OUT(&result[0], ctx->a)
   BOOST_UUID_DETAIL_MD5_OUT(&result[4], ctx->b)
   BOOST_UUID_DETAIL_MD5_OUT(&result[8], ctx->c)
   BOOST_UUID_DETAIL_MD5_OUT(&result[12], ctx->d)
   To:
   BOOST_UUID_DETAIL_MD5_OUT_NEW(&result[0], ctx->a)
   BOOST_UUID_DETAIL_MD5_OUT_NEW(&result[4], ctx->b)
   BOOST_UUID_DETAIL_MD5_OUT_NEW(&result[8], ctx->c)
   BOOST_UUID_DETAIL_MD5_OUT_NEW(&result[12], ctx->d)

Verified the above solution works.

CI: Add coverity scan integration

In the cutover from travis+appveyor to gha, some things got left off to make forward progress. This is one of them.

uuid cannot initialize from list on gcc with boost 1.86

I am seeing a weird error on gcc that I haven't seen before when compiling against boost 1.86:

/home/conda/feedstock_root/build_artifacts/robotraconteur_1723912067148/work/RobotRaconteurCore/src/HardwareTransport_linux.cpp:285:98: error: could not convert '{37, 187, 11, 98, 134, 26, 73, 116, 161, 184, 24, 237, 84, 149, 170, 7}' from '<brace-enclosed initializer list>' to 'boost::uuids::uuid'
  285 |                                                    0xa1, 0xb8, 0x18, 0xed, 0x54, 0x95, 0xaa, 0x07};
      |                                                                                                  ^
      |                                                                                                  |
      |                                                                                                  <brace-enclosed initializer list>

The offending code is this:

boost::uuids::uuid svc_uuid = {0x25, 0xbb, 0x0b, 0x62, 0x86, 0x1a, 0x49, 0x74,
                                                   0xa1, 0xb8, 0x18, 0xed, 0x54, 0x95, 0xaa, 0x07};

This has been working for years with boost version 1.58 through version 1.85.

uuid no longer packable with gcc

There appears to be a breaking change for uuid in version 1.86 where it cannot be packed in a struct using gcc.

I set up an example showing a 1.85 uuid being packed in a struct, but 1.86 uuid causes a warning from gcc: Compile Explorer

gcc warns:

warning: ignoring packed attribute because of unpacked non-POD field

Android: <sys/random.h> not available until API 28

According to the NDK r17b code, in sysroot/usr/include/sys/random.h, it has:

#if __ANDROID_API__ >= 28
int getentropy(void* __buffer, size_t __buffer_size) __wur __INTRODUCED_IN(28);

ssize_t getrandom(void* __buffer, size_t __buffer_size, unsigned int __flags) __wur __INTRODUCED_IN(28);
#endif /* __ANDROID_API__ >= 28 */

Looks like the ::getrandom() function that is used by Boost.UUID in boost/uuid/detail/random_provider_getrandom.ipp is not valid to use. At the moment, with no additional configuration, the UUID library cannot be used on Android (My API is set to 15). I think the fix for this would probably be to have some preprocessor logic that checks if we're on Android, and API less than 28, we do not define BOOST_UUID_RANDOM_PROVIDER_GETRANDOM_HAS_LIBC_WRAPPER, maybe?

not work on ubuntu 16.04.1 LTS

::syscall(SYS_getrandom, buf, size, flags) failed on ubuntu 16.04.1 LTS

location:
uuid/detail/random_provider_getrandom.ipp:70

throws an exception blow:
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::uuids::entropy_error >

system kernel info:
Linux app2 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Unchanged comment in doc.

uuid/include/boost/uuid/detail/sha1.hpp

Line 1 in 33da3e2

// boost/uuid/sha1.hpp header file ----------------------------------------------//

Re-enable serialization tests once project builds on mingw, cygwin in develop branch

boostorg/serialization won't build clean in all the CI jobs boostorg/uuid has, so I disabled the serialization unit tests which eliminated the need to build serialization as part of the uuid CI builds. This should be re-enabled once serialization stabilizes.

Skip header check on deprecated header to avoid a build warning

See: http://www.boost.org/development/tests/develop/developer/uuid.html

Warnings: teeks99-02-dc5-98-Docker-64on64 - uuid / clang-linux-5.0~c++98
Rev 399d61cd34a3a573f1cc083115dd793e68c11cd1 / Wed, 21 Mar 2018 23:55:58 +0000
~hdr-decl-sha1~hpp
../boost/uuid/sha1.hpp:13:9: warning: This header is implementation detail and provided for backwards compatibility. [-W#pragma-messages]
1 warning generated.

Improve messages of string_generator

It would be nice to extend the exception message for
https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/string_generator.hpp

For example:

• "" => "invalid uuid string ''. uuid cannot be empty'
• "123------123" => "invalid uuid string '123------123'. uuid cannot contain consecutive dashes'.
• ...

name_generator changes questionable

I find your name_generator changes questionable. First, you've added an MD5 generator, but there should be no reason for it to ever be used. I don't see how this is an improvement. Second, you've "deprecated" name_generator, which makes no sense, as deprecation implies that a better alternative exists and should be used instead, and it doesn't.

Using name_generator is best practice. Deprecation makes zero sense.

[feature request] Please consider supporting UUID v6 v7 v8 as decribed in RFC 9562

Thanks

#pragma message doesn't show correctly when enabled BOOST_UUID_RANDOM_PROVIDER_SHOW . GCC/Clang

source code godbolat source with boost 1.82

GCC shows
#pragma message("BOOST_UUID_RANDOM_PROVIDER_NAME " BOOST_UUID_RANDOM_PROVIDER_STRINGIFY(BOOST_UUID_RANDOM_PROVIDER_NAME))

Clang shows nothing.

Only MSVC compiler shows correctly: BOOST_UUID_RANDOM_PROVIDER_NAME bcrypt

boost::uuids::random_generator is not copyable in 1.67.0 beta1

From the mailing list:

I just noticed a breaking change: boost::uuids::random_generator is not copyable anymore. Is that is on purpose, it should maybe be mentioned in the release notes.

Linking to bcrypt creates problems (i.e. for CMake users)

As reported in boostorg/boost_install#54, using UUID from a CMake project requires one to manually link to bcrypt on Windows. That's because the CMake config files define BOOST_ALL_NO_LIB, which disables autolinking not just to Boost libraries (which is the intent), but to bcrypt.lib as well.

In addition, since UUID is a header-only library, it has no CMake target to which code could link in order to inherit the dependency to bcrypt.

If we're intending to keep linking to bcrypt, one option here is to create a dummy compiled library, whose only purpose would be to expose a Boost::uuid target in CMake, which would then link to bcrypt.

Avoid undefining BOOST_AUTO_LINK_NOMANGLE if it was previously defined.

Undefining BOOST_AUTO_LINK_NOMANGLE, if it was previously defined, breaks desired behavior of all the boost libraries included after uuid.

Suddenly you will get situation where half of headers link against libname.lib and other half to "fully qualified library name".lib.

CI: add cmake build jobs (use boost-ci)

In the cutover from travis+appveyor to gha, some things got left off to make forward progress. This is one of them.

basic_random_generator not safe in case a = a

uuid/include/boost/uuid/random_generator.hpp

Line 128 in 2bc0c8e

basic_random_generator& operator= (BOOST_RV_REF(basic_random_generator) that) BOOST_NOEXCEPT

Here we should check this == &that for cases when we try to self-assign object of that type. Wy we don't do it right now?

std::data() and std::span support

C++17 introduced std::data() as a means to access the underlying memory block of contiguous container like entities in a generic way. Furthermore C++20 will introduce std::span which has a converting template constructor requiring std::data(cont) to be well formed (side note: we do satisfy the other requirements already). This would let me (and probably others) remove some special handling of uuid when doing IO.

Supporting it is as easy as adding the following two public member function to the uuid class:

BOOST_CONSTEXPR value_type* data() BOOST_NOEXCEPT { return data; }
BOOST_CONSTEXPR value_type const* data() const BOOST_NOEXCEPT { return data; }

Support std::hash

boost::uuids::uuid now supports only boost:hash via hash_value(), making it an unnecessary dependency on platforms supporting >= c++11. There also should be a std::hash specialization.

Consider separating the portable header-only random implementation to another package or library

boost::random maintainer will not accept it - I tried...

Other possibilities or thoughts on this?

uuid on develop (post-1.67) will not build on mingw 32/64 - winapi bcrypt not found

cc: @Lastique

Something changed in winapi - not sure what yet. CI build system caught it on my latest PR:

https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.102-develop/job/6bv0e4ca312n7dyu#L1187

Verified the issue locally, but haven't investigated (yet)...

uuid no longer constexpr contructable

Before version 1.85 uuid was an aggreagate and could be constexpr constructed from a sequence of bytes.
With version 1.85 this is no longer possible.
(I've got user-defined literal which converts uuid string-representation at compile-time into uuids that no longer works with 1.85.)

Consider removing dependency on Boost.TTI

Discussion thread: #114

Fewer dependencies are usually a good thing, just tracking this here.

uuid will not build with -Wextra -Werror -pedantic in clang/gcc

There are various minor issues that need to be resolved, for example:

clang-linux.compile.c++.without-pth ../../../bin.v2/libs/uuid/test/test_random_generator.test/clang-linux-4.0.0/debug/test_random_generator.o
In file included from test_random_generator.cpp:16:
In file included from ../../../boost/random.hpp:60:
../../../boost/random/binomial_distribution.hpp:407:9: error: anonymous types declared in an anonymous union are an extension [-Werror,-Wnested-anon-types]
        struct {
        ^
In file included from test_random_generator.cpp:16:
In file included from ../../../boost/random.hpp:72:
In file included from ../../../boost/random/negative_binomial_distribution.hpp:21:
../../../boost/random/poisson_distribution.hpp:338:9: error: anonymous types declared in an anonymous union are an extension [-Werror,-Wnested-anon-types]
        struct {
        ^
2 errors generated.

and

clang-linux.compile.c++.without-pth ../../../bin.v2/libs/uuid/test/~hdr-decl-uuid_generators~hpp.test/clang-linux-4.0.0/debug/~hdr-decl-uuid_generators~hpp.o
In file included from compile/decl_header.cpp:19:
In file included from ../../../boost/uuid/uuid_generators.hpp:17:
In file included from ../../../boost/uuid/random_generator.hpp:12:
../../../boost/uuid/detail/seed_rng.hpp:226:32: error: cast between pointer-to-function and pointer-to-object is an extension [-Werror,-Wpedantic]
            sha.process_bytes( (unsigned char const*)&std::rand, sizeof( void(*)() ) );
                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

and

gcc.compile.c++ ../../../bin.v2/libs/uuid/test/test_msvc_simd_bug981648.test/gcc-6.3.0/release/debug-symbols-on/test_msvc_simd_bug981648_foo.o
test_msvc_simd_bug981648_foo.cpp: In function ‘void mp_grid_update_marker_parameters(headerProperty*, my_obj&)’:
test_msvc_simd_bug981648_foo.cpp:22:17: error: variable ‘old_header_prop’ set but not used [-Werror=unused-but-set-variable]
 headerProperty *old_header_prop = NULL;
                 ^~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

    "g++"   -O3 -finline-functions -Wno-inline -Wall -pedantic -g -fPIC -m64 -Werror -Wextra -pedantic -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I"../../.." -c -o "../../../bin.v2/libs/uuid/test/test_msvc_simd_bug981648.test/gcc-6.3.0/release/debug-symbols-on/test_msvc_simd_bug981648_foo.o" "test_msvc_simd_bug981648_foo.cpp"

...failed gcc.compile.c++ ../../../bin.v2/libs/uuid/test/test_msvc_simd_bug981648.test/gcc-6.3.0/release/debug-symbols-on/test_msvc_simd_bug981648_foo.o...
...failed updating 1 target...

and

gcc.compile.c++ ../../../bin.v2/libs/uuid/test/test_msvc_simd_bug981648.test/gcc-6.3.0/release/debug-symbols-on/test_msvc_simd_bug981648_foo.o
test_msvc_simd_bug981648_foo.cpp: In function ‘void mp_grid_update_marker_parameters(headerProperty*, my_obj&)’:
test_msvc_simd_bug981648_foo.cpp:28:60: error: format ‘%p’ expects argument of type ‘void*’, but argument 2 has type ‘my_obj*’ [-Werror=format=]
 std::printf("works okay, if it reaches this printf: %p\n",p);
                                                            ^

also from the msvc-14.1 build in appveyor:

ompile-c-c++ bin.v2\libs\uuid\test\test_io.test\msvc-14.1\debug\link-static\threading-multi\test_io.obj
test_io.cpp
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\xutility(2294): warning C4996: 'std::copy::_Unchecked_iterators::_Deprecate': Call to 'std::copy' with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\xutility(2294): note: see declaration of 'std::copy::_Unchecked_iterators::_Deprecate'
C:\projects\boost-root\boost/uuid/uuid_io.hpp(124): note: see reference to function template instantiation '_OutIt std::copy<unsigned char*,boost::uuids::uuid::iterator>(_InIt,_InIt,_OutIt)' being compiled
        with
        [
            _OutIt=boost::uuids::uuid::iterator,
            _InIt=unsigned char *
        ]
libs\uuid\test\test_io.cpp(108): note: see reference to function template instantiation 'std::basic_istream<char,std::char_traits<char>> &boost::uuids::operator >><char,std::char_traits<char>>(std::basic_istream<char,std::char_traits<char>> &,boost::uuids::uuid &)' being compiled
testing.capture-output bin.v2\libs\uuid\test\test_io.test\msvc-14.1\release\link-static\threading-multi\test_io.run

uuid tests don't build as part of 'status'

When trying to run all tests in boost 1.66.0, the build description for the UUID tests fail:

$ cd libs/uuid/test
$ ../../../bjam

Performing configuration checks
    - 32-bit                   : no  (cached)
    - 64-bit                   : yes (cached)
    - arm                      : no  (cached)
    - mips1                    : no  (cached)
    - power                    : no  (cached)
    - sparc                    : no  (cached)
    - x86                      : yes (cached)
    - symlinks supported       : yes (cached)
error: Unable to find file or target named
error:     '/libs/uuid/test//../include/boost/uuid/uuid.hpp'
error: referred to from project at
error:     '.'

The following patch resolves it for me:

diff -Nurp boost_1_66_0.orig/libs/uuid/test/Jamfile.v2 boost_1_66_0/libs/uuid/test/Jamfile.v2
--- boost_1_66_0.orig/libs/uuid/test/Jamfile.v2 2017-12-13 15:56:49.000000000 -0800
+++ boost_1_66_0/libs/uuid/test/Jamfile.v2      2018-03-16 09:06:28.569850135 -0700
@@ -41,12 +41,12 @@ rule test_all
     all_rules += [ compile compile/decl_header.cpp :
         <define>"BOOST_UUID_TEST_HEADER=uuid.hpp"
         <define>"BOOST_UUID_NO_TYPE_TRAITS"
-        <dependency>../include/boost/uuid/uuid.hpp :
+        <dependency>../../../boost/uuid/uuid.hpp :
             compile_uuid_no_type_traits ] ;
     all_rules += [ compile compile/decl_header.cpp :
         <define>"BOOST_UUID_TEST_HEADER=uuid.hpp"
         <define>"BOOST_UUID_NO_SIMD"
-        <dependency>../include/boost/uuid/uuid.hpp :
+        <dependency>../../../boost/uuid/uuid.hpp :
             compile_uuid_no_simd ] ;
     # ECHO All rules: $(all_rules) ;

terminate called after throwing an instance of ... what(): getrandom

I comiled a project against boost library 1.68. When starting this project, I get this error message

bash-4.2# ./run.sh
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::uuids::entropy_error> >'
  what():  getrandom
Aborted

After some googling I found out that this error has something to do with the syscall getrandom and that the syscall was introduced in Linux kernel >= 3.17. On the machine, where I start this project, I have this kernel (it's a CentOS 6.7):

bash-4.2# uname -a
Linux xxx 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue Jan 15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

bash-4.2# cat /etc/*-release
CentOS release 6.7 (Final)

Then I found out that I can rebuild boost with the parameter BOOST_UUID_RANDOM_PROVIDER_FORCE_POSIX, then I could start my project (#79). So I recompiled boost 1.68. This are the commands in a self-written build script:

./bootstrap.sh --with-libraries=atomic,chrono,container,context,contract,coroutine,date_time,exception,fiber,filesystem,graph,graph_parallel,iostreams,locale,log,math,mpi,program_options,random,regex,serialization,stacktrace,system,test,thread,type_erasure,timer,signals,wave

./b2 --layout=tagged define=BOOST_UUID_RANDOM_PROVIDER_FORCE_POSIX toolset=gcc variant=release threading=multi link=shared address-model=64 -sZLIB_SOURCE=$ZLIB_DIR -q -sBZIP2_SOURCE=$BZIP2_DIR

After recompilation of boost 1.68 and my script, I still get this error written above. Is there something I am missing here?

`boost::uuids::random_generator` is not copyable anymore.

Before Boost v1.67, boost::uuids::random_generator was set to the boost random mtwiter random engine which is copyable.
In Boost v1.67 (thankfully and finally) it is not set to that random engine but to a new one based on the platform API. Unfortunately it is now not copyable like the previous implementation.

I'm not sure if required to not be copyable but the change can be problematic.
Would it be possible to make it moveable and copyable?

Getting integer_log2.hpp deprecation warnings

d:\dev\boost.org\boost_1_69_0\boost\pending\integer_log2.hpp(7): note: This header is deprecated. Use <boost/integer/integer_log2.hpp> instead.

This with the latest Boost 1.69.0. I'm assuming this is known at least partly.

The MD5 generated by boost-uuid-1.70.0 and boost-uuid-1.71.0 are different

MD5(1) = C4CA4238A0B923820DCC509A6F75849B based on boost-uuid-1.70.0
while
MD5(1) = 3842CAC48223B9A09A50CC0D9B84756F based on boost-uuid-1.71.0
(https://wandbox.org/permlink/CJ0MMunEhYCRe6Cd)

The 1.70.0 version is right verified by other HASH tools. How to correct it if I want to keep using the version 1.71,0. Thanks in advance.

Release Notes for Boost.Uuid Version 1.68.0

• [phrase library..[@/libs/uuid/ Uuid]:]
  • [*Breaking change:] sha1 detail namespace header redirection for backwards compatibility was removed ([github_pr uuid 69]).
  • Added support for std::hash ([github_pr uuid 67]).
  • Added support for move semantics on random generators ([github_pr uuid 74]).
  • Properly handle EINTR when acquiring entropy ([github_pr uuid 74]).
  • Use getrandom(2) instead of getentropy(3) on linux ([github_pr uuid 75]).