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

[Andreas Rheinhardt]

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.

- Andreas