https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.0 |6.0
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You're right, sorry, I ended up reducing the scope of the fix and it only deals
with PR58038, see https://gcc.gnu.org/ml/libstdc++/2015-03/msg00078.html for
some commentary.
At one point I added:
if (__s < chrono::seconds::zero() || __s < __rtime)
__s = chrono::seconds::max();
which would detect some cases where the duration_cast to chrono::seconds
overflows, but that overflow is still undefined behaviour so I didn't include
that in the commit. I want to fix it properly to avoid any undefined behaviour
(probably converting to duration<long double> and comparing to
duration<time_t>::max()).
> I mean when I sleep for UINT64_MAX hours/years/millenia, you can't possibly
> wrap that into a single nanosleep call due to the limitations of the type
> time_t of the tv_sec parameter of the first argument to nanosleep. One
> obviously can not get around using loop.
To be honest, I'm not very concerned about the failure to sleep for 290 billion
years, if we sleep for duration<time_t>::max() instead of
duration<uint64_t>::max() and don't loop you'll never know the difference.
> Additionally, the nanosleep code is also missing proper EINTR handling,
> which again could break the sleep.
Yes, see the mailing list post above.
I'll deal with this for gcc 6.
