[Ffmpeg-devel] Apropos LRINTF

[Rich Felker]

On Mon, Oct 16, 2006 at 01:52:03PM +0200, Michel Bardiaux wrote:
> No, this is not "again a thread about lrintf missing"!
> 
> Because I need an ultra-super-hyper-optimized rounding function for some 
> app (specifically, julian date calculations), I had a look at how lrintf 
> was supplied and used in ffmpeg. Some things had me puzzled.
> 
> The man page for lrintf says "These  functions round their argument to 
> the nearest integer value, using the current rounding direction". The 
> inline for mingw uses fistpl, which will do just that. Then why is there 
> a comment " better than nothing implementation."?
> 
> Also, this implies that the "current rounding direction" is set, but 
> there is no call (nor stub) to fesetround anywhere. It looks like the 
> intent is rounding towards zero, but then why is the naive C 
> implementation "(int)(x + (x < 0 ? -0.5 : 0.5)" branded as incorrect?
> 
> Why is lrintf used at all, instead of round or trunc? An application 
> using lavc could call fesetround and completely mess up the codecs, no?

Behavior of half of the standard library is undefined if the rounding
direction has been changed, so there's no hope of calling 3rd party
libraries under such circumstances. The only purpose of changing
rounding mode is for doing your own float computations with minimal/no
use of the library routines. You need to set it backafter you're
done..

Rich