Alex Converse <[email protected]> writes: > On Sun, Nov 27, 2011 at 6:07 AM, Mans Rullgard <[email protected]> wrote: >> The existing functions defined in intfloat_readwrite.[ch] are >> both slow and incorrect (infinities are not handled). >> >> This introduces a new header with fast, inline conversion >> functions using direct union punning assuming an IEEE-754 >> system, an assumption already made throughout the code. >> >> The one use of Intel/Motorola extended 80-bit format is >> replaced by simpler code sufficient under the present >> constraints (positive normal values). >> >> The old functions are marked deprecated and retained for >> compatibility. > > Do we think anyone is actually relying on the broken handling for > infinities? I'm inclined to just call this a bug fix. (For the > non-extended precision case)
I sure as hell hope nobody is relying on that. Someone might conceivably be using the functions, however, so they need to be kept in the library for binary compatibility. I also don't like the old names. Especially the "readwrite" part in the filenames is nonsensical. >> Signed-off-by: Mans Rullgard <[email protected]> >> --- >> libavcodec/binkaudio.c | 6 ++-- >> libavformat/4xm.c | 4 +- >> libavformat/aiffdec.c | 10 ++++-- >> libavformat/aiffenc.c | 9 +++-- >> libavformat/cafdec.c | 4 +- >> libavformat/ffmdec.c | 16 +++++----- >> libavformat/ffmenc.c | 16 +++++----- >> libavformat/flvdec.c | 6 ++-- >> libavformat/flvenc.c | 4 +- >> libavformat/gxfenc.c | 6 ++-- >> libavformat/matroskadec.c | 8 ++-- >> libavformat/matroskaenc.c | 4 +- >> libavformat/mov.c | 4 +- >> libavformat/movenc.c | 4 +- >> libavformat/nuv.c | 6 ++-- >> libavformat/rtmppkt.c | 8 ++-- >> libavformat/rtmpproto.c | 6 ++-- >> libavformat/soxdec.c | 6 ++-- >> libavformat/soxenc.c | 6 ++-- >> libavformat/thp.c | 4 +- >> libavformat/wtv.c | 6 ++-- >> libavutil/avutil.h | 4 +- >> libavutil/intfloat.h | 61 >> ++++++++++++++++++++++++++++++++++++++++ >> libavutil/intfloat_readwrite.h | 12 ++++---- >> 24 files changed, 142 insertions(+), 78 deletions(-) >> create mode 100644 libavutil/intfloat.h > > doc/APIchanges? Does anyone actually read those? >> diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c >> index d917e7a..027dce5 100644 >> --- a/libavcodec/binkaudio.c >> +++ b/libavcodec/binkaudio.c >> @@ -189,8 +189,8 @@ static int decode_block(BinkAudioContext *s, int16_t >> *out, int use_dct) >> if (s->version_b) { >> if (get_bits_left(gb) < 64) >> return AVERROR_INVALIDDATA; >> - coeffs[0] = av_int2flt(get_bits(gb, 32)) * s->root; >> - coeffs[1] = av_int2flt(get_bits(gb, 32)) * s->root; >> + coeffs[0] = av_int2float(get_bits_long(gb, 32)) * s->root; >> + coeffs[1] = av_int2float(get_bits_long(gb, 32)) * s->root; > > unrelated fix? The get_bits_long change is unrelated, yes. >> diff --git a/libavutil/intfloat_readwrite.h b/libavutil/intfloat_readwrite.h >> index 10ecbed..f093b92 100644 >> --- a/libavutil/intfloat_readwrite.h >> +++ b/libavutil/intfloat_readwrite.h >> @@ -30,11 +30,11 @@ typedef struct AVExtFloat { >> uint8_t mantissa[8]; >> } AVExtFloat; >> >> -double av_int2dbl(int64_t v) av_const; >> -float av_int2flt(int32_t v) av_const; >> -double av_ext2dbl(const AVExtFloat ext) av_const; >> -int64_t av_dbl2int(double d) av_const; >> -int32_t av_flt2int(float d) av_const; >> -AVExtFloat av_dbl2ext(double d) av_const; >> +attribute_deprecated double av_int2dbl(int64_t v) av_const; >> +attribute_deprecated float av_int2flt(int32_t v) av_const; >> +attribute_deprecated double av_ext2dbl(const AVExtFloat ext) av_const; >> +attribute_deprecated int64_t av_dbl2int(double d) av_const; >> +attribute_deprecated int32_t av_flt2int(float d) av_const; >> +attribute_deprecated AVExtFloat av_dbl2ext(double d) av_const; > > FF_API_ version guard? I don't see the point. The entire file is deprecated. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
