Bug 14870 – incorrect use of assert to detect environmental errors in core.time
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P1
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-08-04T23:44:00Z
Last change time
2015-10-04T18:19:09Z
Keywords
pull
Assigned to
schveiguy
Creator
bugzilla
Comments
Comment #0 by bugzilla — 2015-08-04T23:44:15Z
Note the use of asserts in the following code in core.time:
----
static @property MonoTimeImpl currTime() @trusted nothrow @nogc
{
if(ticksPerSecond == 0)
{
assert(0, "MonoTimeImpl!(ClockType." ~ _clockName ~
") failed to get the frequency of the system's monotonic clock.");
}
version(Windows)
{
long ticks;
if(QueryPerformanceCounter(&ticks) == 0)
{
// This probably cannot happen on Windows 95 or later
assert(0, "Call to QueryPerformanceCounter failed.");
}
return MonoTimeImpl(ticks);
}
else version(OSX)
return MonoTimeImpl(mach_absolute_time());
else version(Posix)
{
timespec ts;
if(clock_gettime(clockArg, &ts) != 0)
assert(0, "Call to clock_gettime failed.");
return MonoTimeImpl(convClockFreq(ts.tv_sec * 1_000_000_000L + ts.tv_nsec,
1_000_000_000L,
ticksPerSecond));
}
}
---
The user should never see assert failures. But apparently, these are happening on some systems. Environment issues should not be tested with assert's. Instead, the issue should be tested for, and if it fails, an error message printed and the program exited with an error status.