On Tuesday, 11 March 2025 03:49:40 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> Let's say we have a header file as follows:
>
> [start]
> constexpr __uint128_t myuuid = _UUID;
> [end]
>
> It won't be difficult to write our own header-only library that
> generates a brand new UUID every time, for every invocation of _UUID.

Correct. Like I said, that's why it's the wrong tool for the job.

What if I have a header that is:

#ifdef __UUID__
STRINGIFY(__UUID__)
#elif defined(__COUNTER__)
hash(__FILE__, __LINE__, __COUNTER__)
#else
# error can't compute unique identifier
#endif


Because I *want* to have more than one:
auto uuid1 =
#include "genuuid.h"
;
auto uuid2 =
#include "genuuid.h"
;

This is a valid use-case. Can you tell me mine is less valid than yours?

> What's a little more difficult is to generate a _UUID which is again
> generated identically for the next build.
> And what's a little more difficult than that is to be able to include
> the above header file in multiple source files, and for it to be the
> same number in all those translation units.

I agree it's more difficult.

Which is why I don't think it's the right tool for the job. And as Arthur
said, if it's supposed to be a Universally Unique identifier, it should be
different every time you ask.

Just generate this header with your buildsystem.

> What would be interesting here is if a constexpr function could have a
> static counter variable, something like:
>
> inline constexpr __uint128_t uuid(void)
> {
> static __uint128_t counter = 0u;
> __uint128_t retval = counter++;
> encrypt_one_block( retval, my_secret_key ); // encrypt
> 128-Bit block with AES128
> return retval;
> }

Which you can do yourself from a single unique identifier.

> It crossed my mind that there could be another strategy to this. If
> anyone's familiar with CTR (or Counter Mode) cryptography, well if we
> use just take successive numbers, i.e. 0, 1, 2, 3, 4, and encrypt them
> with AES128, then we can put the encrypted number into the binary.
> Then after the binary has been built, we can search through the binary
> for the encrypted numbers and replace them. When replacing them, we
> could consult a map to keep track of which one's should be the same
> (e.g. in the case of an inline extern variable defined in a header
> file). If the encryption algorithm is reliable (i.e. appears to be
> adequately random) then we shouldn't get a collision.

Or you can just get the linker's Build ID from the ELF note in the header.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering