fre 2022-10-07 klockan 14:33 +0200 skrev Andreas Rheinhardt:
> 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.)
Right, the presence of (u)int8_t together with ISO/IEC 9899:1999 saying
CHAR_BIT >= 8 does imply CHAR_BIT == 8.
/Tomas
_______________________________________________
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".
