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. > > Regards, > > -- > Nicolas George > > _______________________________________________ > 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
