summaryrefslogtreecommitdiffstats
path: root/libass/ass_fontselect.c
diff options
context:
space:
mode:
authorrcombs <rcombs@rcombs.me>2020-09-16 23:37:02 -0500
committerOleg Oshmyan <chortos@inbox.lv>2020-09-19 17:49:41 +0300
commit9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d (patch)
tree6a0ca65efd623df0dfbce30aecef185d5c60fc98 /libass/ass_fontselect.c
parent6bb17b7e7b783844e66335a7293c82c93ea757d3 (diff)
downloadlibass-9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d.tar.bz2
libass-9b04e56ff6e1ed82bc48ac7307e627bdbbaf082d.tar.xz
ass_parse: avoid UB and match vsfilter on negative-accel color animation
Providing a negative acceleration to \t could result in undefined behavior due to overflow in float->int conversion. This codifies the same behavior we currently have on x86, which matches vsfilter's, without actually invoking UB. Additionally, vsfilter color animations work subtly differently than ours did. We used to lerp each individual color component's byte value, while vsfilter performs the lerp on the component _in place within a larger int_. This didn't result in major issues for most cases, but could probably result in subtle rounding errors, and gave vastly different results for \t with negative acceleration. Negative \t acceleration is probably completely useless, but our behavior was wacky in a different way from vsfilter's, and I'd rather have portable wackiness than libass-specific wackiness. It might still be possible to invoke UB in negative-acceleration \t using tags other than colors; we should fix those cases as well.
Diffstat (limited to 'libass/ass_fontselect.c')
0 files changed, 0 insertions, 0 deletions