Time Remaining overflow error

[csparker247]

I'm seeing an overflow issue with the Time Remaining display for progress bars with long run times and large progress values. The Time Remaining starts at a reasonable run time (lets say 7 hours), decreases normally for a bit, then jumps down to zero and begins counting up. At some point, it resets back to zero and begins counting up again. This final cycle repeats for the duration of the process.

It takes awhile for my process to start up, so it's been hard to capture an example of the beginning state, but here's what it looks like when it cyclically resets back to zero:

This seems like an integer overflow scenario in progress_bar.hpp:257:

        auto eta = std::chrono::nanoseconds(
            progress_ > 0 ? static_cast<long long>(elapsed_.count() *
                                                   max_progress / progress_)
                          : 0);

It doesn't take long (in nanoseconds) for elapsed_.count() * 1325697865 to overflow long long and my specific scenario can be quickly fixed by enforcing a specific order of operations: elapsed_.count() * (max_progress / progress_). I'm happy to submit this as a patch, but this only shifts the issue to an even larger value of max_progress. Should there also be some mention of this issue in the documentation?

[csparker247]

As an alternative here, I wonder if elapsed_ should actually be something like std::chrono::duration<long long>
or std::chrono::duration<long long, std::milli> since we only report durations to the second.

[p-ranav]

Ideally, the tick resolution can be added to the configuration, e.g.,

ProgressBar bar {
  // ...,
  option::TickResolution{TickResolution::milliseconds}
};

That way, the user can configure this setting and it'll work for long-running tasks where the remaining time is in order of minutes.