Observed by statementreply.
In general, we currently do not robustly handle custom arithmetic-like types. Note that we expect this use case to be very uncommon, so this is not a high-priority bug.
Until this is completely addressed, we should make sure to at least fail cleanly if custom arithmetic-like types are used. As an example, we currently use _STD nextafter on a duration::rep that could potentially be a custom arithmetic-like type, in which case it would fail cleanly.
|
} else {
|
|
const auto _Leap_sec_begin = _CHRONO ceil<_CommonType>(_Leap_sec_minus_one + seconds{1});
|
|
_Ticks = _CommonType{_STD nextafter(_Leap_sec_begin.count(), typename _CommonType::rep{0})};
|
|
}
|
Observed by statementreply.
In general, we currently do not robustly handle custom arithmetic-like types. Note that we expect this use case to be very uncommon, so this is not a high-priority bug.
Until this is completely addressed, we should make sure to at least fail cleanly if custom arithmetic-like types are used. As an example, we currently use
_STD nextafteron aduration::repthat could potentially be a custom arithmetic-like type, in which case it would fail cleanly.STL/stl/inc/chrono
Lines 3243 to 3246 in 65eb507