[Ffmpeg-devel] Use of llrint() in mpegaudiodec.c

Michael Niedermayer michaelni
Wed Nov 29 02:39:18 CET 2006


Hi

On Tue, Nov 28, 2006 at 11:38:44PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > Hi
> >
> > On Tue, Nov 28, 2006 at 10:53:24PM +0000, M?ns Rullg?rd wrote:
> >> Benjamin Larsson <banan at student.ltu.se> writes:
> >> 
> >> > M?ns Rullg?rd wrote:
> >> >
> >> >>In mpegaudiodec.c there are two calls to llrint().  This function
> >> >>isn't available on some platforms, so linking fails there.  Looking
> >> >>closer, I notice that in both cases, the return value is immediately
> >> >>assigned to a 32-bit variable.  This makes be think that using lrint()
> >> >>should work equally well, and lrint() is more widely available than
> >> >>llrint().  Is there some subtle issue I'm missing here, or is the
> >> >>attached patch safe?
> >> >>  
> >> >>
> >> >
> >> > This is the commit message that added this code:
> >> >
> >> > http://thread.gmane.org/gmane.comp.video.ffmpeg.cvs/4408/focus=4408
> >> >
> >> > Some systems didn't like lrint() either, so I suggest to go by the
> >> > integer rounding route that Michael suggested later in the thread.
> >> 
> >> That still doesn't explain why llrint() is used, even though the
> >> return value is immediately converted to 32 bits.  Michael's second
> >> suggestion also involves unexplained 64-bit types.
> >
> > _IIRC_ some values didnt fit in an 32bit int and caused a floating
> > point exception, adding a check for >MAX should work too but its
> > more complex ...
> 
> Hmm, so some values are too large for signed 32-bit but fit in
> unsigned 32-bit?  

i dont know, maybe they dont fit in 32bit unsigned either, probably they
are unused, feel free to RTFS / RTFspec and make the table smaller
and yes i did check that all the values which are used didnt overflow
the unsigned range when i wrote the code ...
also feel free to add comments to the code about the valid range of
values for various variables ...


> That would explain things.  So how should we
> properly fix this?  We *could* of course ignore it and let it break on
> cygwin...

ignoring isnt ideal
except that i dont care how its fixed as long as it works and is not
too messy but i have no doubt that your code n case you fix it will
be nice and clean ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list