[FFmpeg-cvslog] r21735 - trunk/libavutil/internal.h

[Måns Rullgård]

Michael Kostylev <michael.kostylev at gmail.com> writes:

> On Fri Feb 19 19:44:04 2010
> M?ns Rullg?rd wrote:
>
>>>>>>> On Tue Feb  9 23:55:16 2010
>>>>>>> mru wrote:
>>>>>>>
>>>>>>>> Define missing llrint() as macro instead of inline function
>>>>>>>> 
>>>>>>>> This fixes building on some broken systems.
>>>>>>>> 
>>>>>>>> Modified:
>>>>>>>>    trunk/libavutil/internal.h
>>>>>>>> 
>>>>>>>> Modified: trunk/libavutil/internal.h
>>>>>>>> ==============================================================================
>>>>>>>> --- trunk/libavutil/internal.h	Tue Feb  9 23:55:13 2010	(r21734)
>>>>>>>> +++ trunk/libavutil/internal.h	Tue Feb  9 23:55:16 2010	(r21735)
>>>>>>>> @@ -225,10 +225,8 @@ static inline av_const unsigned int ff_s
>>>>>>>>  #endif /* HAVE_EXP2F */
>>>>>>>>  
>>>>>>>>  #if !HAVE_LLRINT
>>>>>>>> -static av_always_inline av_const long long llrint(double x)
>>>>>>>> -{
>>>>>>>> -    return rint(x);
>>>>>>>> -}
>>>>>>>> +#undef llrint
>>>>>>>> +#define llrint(x) rint(x)
>>>>>>>
>>>>>>> The dos machine is unhappy with this macro.
>>>>>> 
>>>>>> Please elaborate.
>>>>>
>>>>> A bunch of tests from the regression suite and the idroq-video-encode
>>>>> test no longer pass since r21735 (reverting it or applying a quick
>>>>> hack attached in the previous message make them pass again).
>>>> 
>>>> Weird.  Which call to llrint() is causing the trouble?
>>>
>>> libavcodec/opt.c, line 67:
>>>     case FF_OPT_TYPE_INT:   *(int       *)dst= llrint(num/den)*intnum; break;
>> 
>> Applying your cast to that expression should have no effect at all
>> since the usual arithmetic conversions already specify that action.
>
> Under dos the argument of rint might be too big, e.g. 0xa0080004.0/1 while
> normally it should be equal to 0x80004.0/1.

How the hell does casting the *result* fix a problem with the *argument*?

-- 
M?ns Rullg?rd
mans at mansr.com