"Ronald S. Bultje" <rsbul...@gmail.com> writes:
> Hi,
>
> On Mon, Jul 30, 2012 at 10:26 AM, Alex Converse <alex.conve...@gmail.com>
> wrote:
>> On Mon, Jul 30, 2012 at 10:07 AM, Ronald S. Bultje <rsbul...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> On Wed, Jul 25, 2012 at 10:40 PM, Luca Barbato <lu_z...@gentoo.org> wrote:
>>>> On 07/26/2012 05:37 AM, Ronald S. Bultje wrote:
>>>>> From: "Ronald S. Bultje" <rsbul...@gmail.com>
>>>>>
>>>>> ---
>>>>> libavutil/eval.c | 35 +++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 35 insertions(+)
>>>>>
>>>>
>>>> As for the snprintf, I'd rather have those workaround in os_support,
>>>> move it to libavutil and have os_support.h included.
>>>>
>>>> I'd move this code to
>>>>
>>>> ff_strtod()
>>>>
>>>> and have #define strtod ff_strtod
>>>
>>> I'm a little bit concerned about having a function called ff_strtod()
>>> which is only called from a function called av_strtod().
>>>
>>
>> What about avpriv_strtod_internal()
>>
>> The longer name makes it less likely someone will use it accidentally
>> and the avpriv_ prefix should allow it to be used in all of the
>> libraries.
>
> My point is more that it seems we want people to use av_strtod(), so
> making it externally visible is not necessary. Although the data
> speaks against that:
>
> $ grep strtod ../lib{avcodec,avformat,avfilter,avresample,avutil,swscale}/*.c
> ../libavformat/rtmpproto.c: ff_amf_write_number(p, strtod(value,
> NULL));
> ../libavfilter/vf_frei0r.c: val.d = strtod(param, &tail);
> ../libavutil/eval.c:double av_strtod(const char *numstr, char **tail)
> ../libavutil/eval.c: d = strtod(numstr, &next);
> ../libavutil/eval.c: d->value = av_strtod(p->s, &next);
> ../libavutil/parseutils.c: alpha = 255 * strtod(alpha_string,
> &tail);
>
> Why is av_strtod() externally visible instead of static, if it is
> completely unused?
It is not unused.
> Should all uses of strtod() use av_strtod()?
No.
av_strtod() allows SI multipliers (k, M, etc) after a numerical value.
Uses where this is not desired should use the plain strtod().
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
