Andrew Fish [mailto:[email protected]] wrote:
On Sep 16, 2014, at 10:53 AM, Scott Duplichan <[email protected]
<mailto:[email protected]> > wrote:
Tian, Feng [ <mailto:[email protected]> mailto:[email protected]] wrote:
]Hi, Andrew
]
]The change was proposed to solve incorrect truncation and overflow issue on
old revision.
]
]The original code is:
] Counter = (UINT32) DivU64x32Remainder (
] Microseconds * 10,
] gMetronome->TickPeriod,
] &Remainder
] );
]
]In original code, there is Microseconds * 10 which may be out of UINTN
boundary. And Counter is forced to truncate to 32 bit,
]which may also bring issue.
Well checking for a delay of 58,455 years is not solving a real problem, at
least not one we can test. Making sure the 7 minute
stall works is probably the problem you want to solve.
It is good to see concern over integer overflow. So often it is just ignored.
Here is an example. Which delay is longer:
MicroSecondDelay (5153376776577);
MicroSecondDelay (1);
That seems like a bug, which TimerLib library instance is this? We should fix
it. Scott do you have a system that can sit around for
60 days running the test?
Hello Andrew,
The above overflow is from DuetTimerLib, one that uses the ACPI timer. Probably
a similar overflow could be demonstrated for the
ones using APIC timer. In many ways it is in the same category as 58,000 year
delay problem. It really doesn't matter.
Thanks,
Scott
Thanks,
Andrew Fish
Answer: the second one. The first malfunctions due to integer overflow.
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
