f
On Sep 16, 2014, at 10:53 AM, Scott Duplichan <[email protected]> wrote:
> Tian, Feng [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?
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
