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. -- Anton Khirnov _______________________________________________ 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".
