[FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> 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
>>> optimization.
>>>
>>> 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
>>> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
>>> "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
>>> determined".
>>>
>>> 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
>> realistic.
>
> 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
> good reason.
>

I think an important point to remember is that we have plenty of areas
that could use improvement right now, on platforms relevant today.
We don't need to keep ourselves busy worrying about some theoretical
future system that may or may not exist in a decade or so.

If you want to waste your time on that, noone is going to stop you,
just don't expect much support from other developers, whose time may
be much better spent on things affecting this decade.

- Hendrik