[FFmpeg-devel] [PATCH 0/2] first steps to resolving float to int undefined behavior

Ganesh Ajjanagadde gajjanag at mit.edu
Mon Nov 2 00:51:19 CET 2015

On Sun, Nov 1, 2015 at 6:25 PM, Nicolas George <george at 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:, 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.

> Regards,
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list