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

Ganesh Ajjanagadde gajjanag at mit.edu
Wed Oct 21 12:00:21 CEST 2015

On Wed, Oct 21, 2015 at 5:31 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> 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.

I don't "expect support" from anyone. Frankly, I have dealt with
enough mud from you, who seems to take great pleasure in criticizing
or otherwise derailing every patch/discussion of mine to not care
about things either way - if you don't want me, just say the word, and
I will be gone. And your own stance on this point is not even clear -
GCC 20 is not going to hit the shelves this decade.

Since you seem to be an "expert" on what things affect this decade,
why don't you spend 5 minutes trying to outline to beginners like me
what is "actually important" in your view?

> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list