[FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea
gajjanag at mit.edu
Wed Oct 21 11:10:53 CEST 2015
On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu <timothygu99 at gmail.com> wrote:
> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> Hi all,
>> It is known that there exist at least certain parts of the codebase
>> that do not work correctly if ints are 64 bits. One of them I noticed
>> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
>> int is 64 bits. This is true both before and after the De-Bruijn
>> A more interesting (and serious) question is whether FATE is broken if
>> int's are 64 bits. I did some digging, and found the following from
>> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
>> -mint64, documented as follows (see e.g
>> "Force int and long types to be 64 bits wide. See -mlong32 for an
>> explanation of the default and the way that the pointer size is
>> This should be helpful in setting up a FATE client to test (and
>> possibly fix) bad code that assumed int = 32 bits. I myself can't
>> easily run such an outdated GCC, but I noticed a bunch of clients
>> running GCC < 4.0 where this may be set up.
> For lack of milder wording, this is a terrible idea.
> FATE is set up, not to test every single possible combination of compiler,
> compiler flags, and operating system, but to make sure FFmpeg works on the
> ones people actually use. There are already not many people using GCC 3,
> and the addition of a flag that completely changes the API is nowhere near
Int being 64 bits is not as unrealistic as one can expect. Sure, right
now we have no such platform. However, computer architecture people
definitely do talk seriously about moving to 128 bit (or wider)
architectures. On the GCC/Glibc mailing lists, people do discuss these
things every now and then. Furthermore, how does this change the API?
On an int = 64 bits platform (with all libraries built accordingly),
people would still call/pass in int's when they are needed, right?
> Sometimes it's necessary to draw a line between "what's written in ISO/IEC
> 9899" and "real world."
I admit it is "theoretical" at the moment, but Michael did express
some interest in testing this idea, suggesting some level of
consideration in FFmpeg. In the "real world", a lot of "undefined
behavior" has well defined, consistent semantics on all platforms we
care about. For instance, negative left shifts are handled by both GCC
and clang in the same way. Does that mean we should just ignore it?
Not by any means. FFmpeg cares about portability and robustness, with
In other words: I recall Nicolas mentioning that FFmpeg could do with
using width specific types more liberally. If I see a patch which
causes additional potential trouble if/when int's become 64 bits, I
will raise the point.
> Plus Mark's point on technical possibility of it (thank GOD GCC didn't do
> something as crazy as this on other platforms).
Indeed, it is very fortunate that GCC does not do this on other
platforms. That does not change whether we should test it or not.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel