Tomas Härdin: > fre 2022-10-07 klockan 12:38 +0200 skrev Andreas Rheinhardt: >> Tomas Härdin: >>> tor 2022-10-06 klockan 21:45 +1100 skrev Peter Ross: >>>> >>>> +static av_cold int vqc_decode_init(AVCodecContext * avctx) >>>> +{ >>>> + static AVOnce init_static_once = AV_ONCE_INIT; >>>> + VqcContext *s = avctx->priv_data; >>>> + >>>> + s->vectors = av_malloc((avctx->width * avctx->height * 3) / >>>> 2); >>>> + if (!s->vectors) >>>> + return AVERROR(ENOMEM); >>>> + >>>> + s->coeff = av_malloc(2 * avctx->width * sizeof(int16_t)); >>>> + if (!s->coeff) >>>> + return AVERROR(ENOMEM); >>>> + >>>> + s->tmp1 = av_malloc(avctx->width * sizeof(int16_t) / 2); >>>> + if (!s->tmp1) >>>> + return AVERROR(ENOMEM); >>>> + >>>> + s->tmp2 = av_malloc(avctx->width * sizeof(int16_t) / 2); >>> >>> av_malloc_array() perhaps? Not that these are likely to overflow >>> since >>> max pixels is usually far away from INT_MAX >>> >> >> Actually, sizeof(int16_t) is guaranteed to be two, so that >> sizeof(int16_t) / 2 is always one. > > Not on machines where CHAR_BIT >= 16. But we could enforce that during > configuration >
The fixed-wide integers are required by the spec to have no padding. We rely on uint8_t/int8_t to be present and so CHAR_BIT divides 8, but it has to be >= 8, too, so it is eight. (Apart from that, we probably rely on CHAR_BIT to be eight in thousands of other places, too.) - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".