[FFmpeg-devel] [PATCH 01/11] ffmpeg: use log10 instead of log()/log(10)

[Ronald S. Bultje]

Hi,

On Thu, Oct 29, 2015 at 8:32 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
wrote:

> On Thu, Oct 29, 2015 at 8:27 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> > Hi,
> >
> > On Thu, Oct 29, 2015 at 8:04 AM, Michael Niedermayer
> <michael at niedermayer.cc
> >> wrote:
> >
> >> On Thu, Oct 29, 2015 at 12:19:59AM -0400, Ganesh Ajjanagadde wrote:
> >> > This is more concise and conveys the intent better.
> >> > Furthermore, it is likely more precise as well due to lack of floating
> >> > point division.
> >> >
> >> > Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
> >>
> >> patchset tested on linux32, inux64, mingw32, ming64, qemu-mips and
> >> qemu-arm
> >> fate passes on all, i could test on actual arm&mips hw if people think
> >> that is needed
> >
> >
> > I don't think that's needed.
> >
> > Is there some way we can confirm that each of these files that is changed
> > includes libavutil/libm.h for the compatibility macros in case they're
> > lacking on the target system?
>
> Don't know, but in case any were wondering: I assumed the availability
> simply because existing code already used log2, log10. This is also
> why even without the accuracy change, I personally consider the
> patchset an improvement due to it making FFmpeg more consistent in its
> choice of log function.


The risk is that some file in the dusty corners of our codebase forgets to
include libavutil/libm.h, the system does not have log2 or whatnot (which
is exactly why we have the compat wrappers in libavutil/libm.h - they are
not there because somebody felt like writing it just in case it happens -
they were written because it _did_ happen), and as a result it fails to
compile when a user on aix or msvc2010 or whatever affected system tries to
compile the next release.

That would suck, and users would think ffmpeg sucks as a result. So that's
why I'm wondering if we can confirm that all affected files do include
libavutil/libm.h, so that we can be sure there's nothing to worry about.

Ronald