> > So basically, this takes a long long value, and casts it to a long. > > Yes, but that's not the entire story. > > the function declaration is: long nextTimeout(int resolution) > > So it would truncate anyway. But look at it closer. It > takes the value of timeval.tv_sec (your time_t / long long) > and mod's it with resolution (an int value). The only thing > it then does is multiply it by 1000L. > > The only reason this function "broke" is C++'s std::max() > defined as a template function, requiring both args be of > the same typename. Since the original code uses 1000L > literal for the first arg, the compiler was having issues with > the long long as the second arg., but ... > > What is long long % int? another int value? Yes, I realize > it would be a long long according to the compiler, but, > I fail to see where/how 0xFFFFFFFFFFFFFFFF % 0xFF would > ever be greater than 0xfe. > > As is, the best you can expect from that function is a long > second argument for std::max(). Unless I'm completely missing > something here (and I'll certainly budget for that possibility).
You're completely missing the point. We provide an opportunity to the entire community to fix things in the best way possible. And you squander it. The solution is to take all the subsystems and arguments to time_t, throughout the entire program, and then do the best from there. Instead, you chose to prematurely downcast.
