On Sun, Nov 1, 2015 at 7:15 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sun, Nov 01, 2015 at 06:51:19PM -0500, Ganesh Ajjanagadde wrote:
>> On Sun, Nov 1, 2015 at 6:25 PM, Nicolas George <geo...@nsup.org> wrote:
>> > Le primidi 11 brumaire, an CCXXIV, Ronald S. Bultje a écrit :
>> >> So, is this a bug in llrint, or is this a failure to use llrint, or is
>> >> this
>> >> different from llrint? It sounds to me that llrint should be used, not our
>> >> own alternative.
>> >
>> > Is there a sized version of the function? int64rint? Otherwise, these
>> > functions for the native types are as useless as the native types
>> > themselves.
>>
>> No, not in ISO C, or even libc AFAIK. ISO C tends to favor the
>> "non-sized" types in their signatures. The reason (I believe) stems
>> from the fact that an implementation is free to not even define the
>> sized types:
>> 7.20.1.1, point 3 - "These types are optional. However, if an
>> implementation provides integer types with widths of 8, 16, 32, or 64
>> bits, no padding bits, and (for the signed types) that have a two’s
>> complement representation [all platforms supported by the project], it
>> shall define the corresponding typedef names." -
>> Thus they want to limit their scope to mostly (or perharps only?) stdint.h.
>>
>> Even otherwise, these functions are somewhat useless due to the
>> undefined behavior outside the range. All they really do is get
>> rounding done correctly according to the current FPU environment and
>> associated rounding modes, which can be manipulated in C99/C11.
>
> quite some of the undefined behavior also makes more optimizations
> possible for advanced compilers
> random silly example
>
> min = 0;
> for(i=0; i<N; i++) {
> float c = whatever()
> min = fmin(min, c);
> out[i] = llrint(c);
> }
>
> here the compiler can remove any and all handling of NaN and +-Inf
> from fmin() because llrint(c) implies c is within the range
> represetable of the integer types
>
> with a llrint() equivalent that is defined for all cases this is not
> possible anymore
Yes, which is why I have mentioned that we need to use a safe version
only when we need to guarantee safety, and are dealing with arbitrary
doubles. But such cases are there, such as the ffserver_config patch I
posted.
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> During times of universal deceit, telling the truth becomes a
> revolutionary act. -- George Orwell
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
