aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/xga_font_data.h
diff options
context:
space:
mode:
authorFrank Plowman <post@frankplowman.com>2023-12-22 12:00:01 +0000
committerMartin Storsjö <martin@martin.st>2024-01-04 14:44:11 +0200
commit42982b5a5d461530a792e69b3e8abdd9d6d67052 (patch)
tree525126791c3ef73464b761fe7ddb8e37bee98295 /libavutil/xga_font_data.h
parent6caf34dbe0f0e406c49394c6c6552cc1345957b7 (diff)
downloadffmpeg-42982b5a5d461530a792e69b3e8abdd9d6d67052.tar.gz
avformat/ffrtmpcrypt: Fix int-conversion warning
The gcrypt definition of `bn_new` used to use the return statement on errors, with an AVERROR return value, regardless of the signature of the function where the macro is used - it is called in `dh_generate_key` and `ff_dh_init` which return pointers. As a result, compiling with gcrypt and the ffrtmpcrypt protocol resulted in an int-conversion warning. GCC 14 may upgrade these to errors [1]. This patch fixes the problem by changing the macro to remove `AVERROR` and instead set `bn` to null if the allocation fails. This is the behaviour of all the other `bn_new` implementations and so the result is already checked at all the callsites. AFAICT, this should be the only change needed to get ffmpeg off Fedora's naughty list of projects with warnings which may be upgraded to errors in GCC 14 [2]. [1]: https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html [2]: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg196024.html Signed-off-by: Frank Plowman <post@frankplowman.com> Signed-off-by: Martin Storsjö <martin@martin.st>
Diffstat (limited to 'libavutil/xga_font_data.h')
0 files changed, 0 insertions, 0 deletions