> > > 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.
Now, before you say this is impossible or ridiculous, let me say this. We did what I suggest to the entire base tree, before the kernel changes were commited. If we can do this to the entire base tree system -- something much much larger than the average package, then people working in the ports tree can at least try to not squander the opportunity. Please & thanks.
