Thiago,

Re-reading your mail, I think I see the points you’re trying to make more clearly and they do make sense.

I am not sure how the best way to handle some of the concerns you raise, but I’ll give it some thought overnight and try to push an updated spec, that is more explicit about the limitations, attempts to address some of the concerns and gives some thoughts to the ODR issues that have been raised.

Best regards,

Nik

On Thu, Mar 6, 2025 at 20:44, Thiago Macieira <[thiago_at_[hidden]](mailto:On Thu, Mar 6, 2025 at 20:44, Thiago Macieira <<a href=)> wrote:

> On Thursday, 6 March 2025 16:20:33 Pacific Standard Time Nikolaos D. Bougalis
>> But that distracts from the question of whether having the ability to do
>> this in C++ is a useful tool to offer to developers.
>
> Indeed, but I feel that the use-cases for it are too narrow and misleading,
> while the fall out could be big.
>
>> > * implementations are encouraged to have a mechanism to configure what
>> > time
>> > point is returned by this function, so as to support reproducible and
>> > deterministic builds, such as SOURCE_DATE_EPOCH environment variable (link
>> > to https://reproducible-builds.org/ for more information)
>>
>> If I were being pedantic, I'd argue that it's possible to just roll back the
>> system clock, and in some ways easier. But I don't think it's a bad idea to
>> encourage implementations to provide such a mechanism.
>
> Indeed, and for strict reproduceability, it might be necessary to LD_PRELOAD a
> module that overrides gettimeofday() and clock_gettime(), in case the
> buildsystem is creating the time string or value to supply to the compilation.
>
>> > * reliability, accuracy, and precision are not guaranteed. Many systems
>> > may
>> > not know their timezone or be synchronised with an atomic clock. Some
>>
>> Nothing in my proposal should really be construed as mandating an accurate
>> clock anymore than the standard can mandate `std::chrono::system_clock` to
>> be accurate. All my proposal requires is to effectively return a time_point
>> at compile time. I was doing some embedded development the other day and
>> `std::chrono::system_clock` always starts on January 1, 2018 at 00:00:00
>> when you reset the device, because that's what the microcontroller is
>> configured. I believe that's perfectly compliant with the standard already.
>
> Right. I was just being thorough. This point was to support the fact that you
> can just parse __DATE__ and __TIME__, because it's going to give you a value
> that is as correct as any.
>
>> > * software cannot depend on the date returned changing at all. A compliant
>> > compiler is allowed to return a fixed date, either intentionally or
>> > because the build environment is misconfigured (e.g., unable to obtain a
>> > time after boot - my coffee maker has been showing "12:00" for the past 3
>> > days). Therefore, software cannot depend on this value to generate unique
>> > identifiers because they may not be unique at all.
>>
>> I understand that you are trying to be helpful, and I am trying to read your
>> suggestions with that in mind, but I can't help but feel that you're also
>> trying to water the proposed functionality down to what amounts to
>> homeopathic levels.
>
> It wasn't the intention when I wrote the bullet points. But I did realise that
> was the outcome when I finished the email.
>
> Either way, the fact is that software cannot depend on the uniqueness or
> monotonicity of the value returned by this function, unless the developer
> controls the environment in question (compiler vendor and version, OS, boot
> sequence, etc.). Therefore, I do suggest you water down your use-case of
> unique IDs. Don't suggest in any way that they are unique; instead, you can
> suggest that they are better than nothing, to be used as a fallback in case a
> better solution isn't available at runtime.
>
>> Even if your coffee maker is misconfigured and showing "12:00" for the past
>> three days, I'm betting it knows the seconds since boot anyways. Having an
>> clock that can return meaningful durations is a useful thing, even if it
>> cannot return "correct" time.
>
> That's the steady_clock but you aren't suggesting we use it.
>
>> > I also think you can implement a clock using DATE and TIME because
>> > the clock is not expected to be accurate.
>>
>> Sure, you can implement a clock but never changes, and it will be right
>> twice a day on some timezone. But as I said before, the question is whether
>> such a thing is _useful_.
>
> That was not the point here. My point is that you can get a reasonably-close
> current time_point using __DATE__ and __TIME__, in spite of those not
> including the timezone. Assuming the OS's date is correct in the first place,
> the result of this will be correct to within -12h/+14h30.
>
>> Sure, you could do it. It would be a non-steady clock (which the standard
>> does allow!) but it wouldn't really be a useful clock. If this was a
>> real-world analogy, I'm asking for us to provide people with clocks and
>> your response basically amounts to: "let's print out a picture of a clock
>> and give them that... what do they need a clock for?"
>
> My argument is that it's *as* useful as the expected implementation of
> returning the system_clock::now() at the time the compiler evaluated the
> expression or, more likely, at the time that the compiler created __DATE__ and
> __TIME__.
>
>> The key point of the C++ standard (or any standard really) is that it
>> provides guarantees that those who build on top of that standard can rely
>> on.
>
> But they can't rely on anything here! That's my whole point: given that
> environments can be misconfigured and given that reproduceability will exist
> allowing the compilers to lie, the value that the function returns may bear no
> resemblance to reality.
>
> And it's not unreasonable to have an implementation that, by default, provides
> a fixed date. For example, for some industries due to regulation, software
> developers may be required to provide attestation through reproduceability. So
> I could see companies targeting the medical industry (such as Green Hills)
> simply deciding that midnight on May 20, 1875 is a correct date. That would
> make it both perfectly reproducible and also reveal where it attempted to
> violate this requirement by saying it's been 150 years since it was compiled.
>
>> The C++ standard cannot and does not mandate a reliable system clock any
>> more than it mandates, say, what the underlying implementation of
>> `std::random_device` is. All it mandates is certain characteristics.
>> Nothing in this proposal changes those characteristics. But it does aim to
>> deliver concrete and well-defined behavior to solve a specific problem--or
>> rather, what I perceive to be a specific problem; ymmv.
>
> Right. And you're not proposing a constexpr std::random_device (yet, anyway).
>
> I understand that you're not calling for a change of the characteristics. But
> I am calling into question at least one of the motivations, because it relies
> on those very characteristics having changed.
>
>> While I agree that we should be clear about what "well-defined" means in
>> this context and should be clear about what
>> `std::chrono::system_clock::now()` does in the context of a constant
>> expression and about the limitations, I don't think we should hollow the
>> proposal out so completely as to basically have it no longer serve a
>> purpose.
>
> I think the proposal text should be clear on the limitations. Even if that
> portion of the proposal does not end up in the standard text itself, the
> proposal will be read by compiler implementors and other software developers,
> which may inform them on what to do and not do.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering