[FFmpeg-devel] [PATCH 1/2] avcodec/movtextenc: Check for too many styles

[Guo, Yejun]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年2月24日 3:53
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/movtextenc: Check for too
> many styles
> 
> Anton Khirnov:
> > Quoting Guo, Yejun (2021-02-21 06:31:37)
> >>
> >>
> >>>>
> >>> FYI: The C standard does not mandate the sizes for most types (the uintx_t
> >>> types are an exception). It also gives the compiler absolute freedom on
> how
> >>> much padding to add to a structure. A compiler could very well add
> megabytes
> >>> of padding to StyleBox. The numbers you provide only pertain to one (or
> >>> actually none, see below) implementation, not to all of them. It is like
> >>> someone claiming to prove a general theorem by only checking it for one
> >>> example.
> >>>
> >>> Several of your statements are btw not only false for a hypothetical system
> >>> compliant with the C standard. They are false on common systems:
> >>> "SIZE_MAX / sizeof(*s->style_attributes) is always larger than uint_max"
> >>> is wrong on ordinary 32bit systems (where SIZE_MAX and UINT_MAX
> typically
> >>> coincide). And "sizeof(*s->style_attributes) is 12". Due to padding it is
> normally
> >>> 16; it could be reduced to 12 (for ordinary
> >>> systems) by rearranging its elements.
> >>>
> >>
> >> thanks for the lucid explanation, yes, you're right.
> >> (and first to know that megabytes of padding is possible)
> >>
> >> btw, just as a learning, is there possible a real system where uint_max <
> uint32_max?
> >> If no, we might say that: size_max >= uint_max >= uint32_max >
> uint16_max.
> >
> > We assume int (and hence also unsigned int) is at least 32bit.
> > But AFAIK the only limit on size_t is that it's at least 16bit,
> > otherwise it can be smaller than int.
> >
> While it is true that the smallest permissible value of SIZE_MAX is
> 65535, we de facto require it to be much greater: We never check for
> truncation when using any allocation function with an unsigned
> parameter, ergo we rely on SIZE_MAX >= UINT_MAX. And some of our
> structures don't fit into 65535B (e.g. the context of the DVB subtitles
> decoder contains an "int clut_count2[257][256]") as do other objects (we
> seem to have at least 40 objects with a size >= 65536; the biggest is
> the VLC table for atrac3plus); H.2645 packets are even padded with
> 256KiB (see MAX_MBPAIR_SIZE). The latter would lead to nonsense
> behaviour on a system with SIZE_MAX == 65535, while the other two would
> lead to compilation errors.

got it, thanks Andreas and Anton.