The incorrect way to compute the roll-over in WIN32 osdTime.cpp
Bug #697519 reported by
Alex Chen
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
Medium
|
Unassigned | ||
3.14 |
Fix Released
|
Medium
|
Jeff Hill |
Bug Description
EPICS Base 3.14.9
File: \src\libCom\
May occurs in other files.
Problem:
There are a lot of places in this file to handle the roll-over case. e.g. at line 379, ' offset = ( MAXLONGLONG - this->lastPerfC
Changed in epics-base: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Jeff Hill (johill-lanl) |
milestone: | none → 3.14.branch |
no longer affects: | epics-base/3.15 |
Changed in epics-base: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Jeff,
This code does look wrong, maybe the second MAXLONGLONG was supposed to be MINLONGLONG instead? Even in that case though I suspect there's an off-by-1 error in the result:
if ( curPerfCounter. QuadPart >= this->lastPerfC ounter ) { QuadPart - this->lastPerfC ounter; +18/perf_ freq sec to roll over this ounter )
+ ( curPerfCounter. QuadPart + MAXLONGLONG );
offset = curPerfCounter.
}
else {
//
// must have been a timer roll-over event
//
// It takes 9.223372036855e
// counter. This is currently about 245118 years using the perf
// counter freq value on my system (1193182). Nevertheless, I
// have code for this situation because the performance
// counter resolution will more than likely improve over time.
//
offset = ( MAXLONGLONG - this->lastPerfC
}