If you want reproducible numbers, why not use a parameter to identify the specific id instead of using counters or hashing files?   Seed + Parameter = uuid   That would work with multiple TUs, too   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 11.03.2025 11:50 Betreff:Re: [std-proposals] Random numbers in identical builds An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Tue, Mar 11, 2025 at 12:18 AM Thiago Macieira wrote: > > On Monday, 10 March 2025 16:36:12 Frederick Virchanza Gotham wrote: > > > > The only question though is what is the desired behaviour if a > > constexpr UUID is generated in a header file? Should each translation > > unit get a unique UUID, or should the same UUID be shared among all > > the translation units (even if the constexpr variable has internal > > linkage)? > > The answer to that is why it should not be in the compiler. If you need to > know which one it is, then you should control it yourself by having your build > system control it. The reason why I'm talking about it here, rather than on Stack Overflow or Reddit or whatever, is that compiler support might be needed. 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. 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. The above variable has internal linkage because it's constexpr. We could change it to:    [ start of "myheader.hpp" ]    extern inline constexpr __uint128_t myuuid = _UUID;    [ end of "myheader.hpp" ] 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;    } We could then make this function "extern inline" if the counter will be shared among all the translation units, or "static inline" if each translation unit should have its own counter. And then perhaps the programmer would have a choice of two functions, "uuid_global" or "uuid_this_transunit" (i.e. external linkage Vs internal linkage). But even if we use uuid_global, we might get different values for the UUID if the multiple source files are built in parallel. I think what would really need compiler support though is a situation such as the following:    [ beginning of 1st source file ]    #include <cstdlib>    // EXIT_FAILURE    #include "myheader.hpp"    int main(void)    {        return (myuuid & 8u) ? 0u : EXIT_FAILURE;    }    [end of 1st source file ]    [ beginning of 2nd source file ]    extern inline constexpr __uint128_t my_other_uuid = _UUID;    #include "myheader.hpp"    extern bool SomeFunc(void)    {        return myuuid & 8u;    }    [end of 2nd source file ] The problem with the above program is that the 2nd source file will generate a different UUID for "myuuid" because the counter will be 1 instead of 0. 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals