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

[Ganesh Ajjanagadde]

On Thu, Oct 29, 2015 at 8:44 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 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.

Thanks for clarifying.

>
> 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.

Indeed.

>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel