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

wm4 nfxjfg at googlemail.com
Wed Oct 21 12:18:44 CEST 2015


On Wed, 21 Oct 2015 06:00:21 -0400
Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:

> 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.

Nobody is throwing mud at you. But your patches are mostly
"theoretical" changes, often without much proof that they are really
necessary, or cosmetic changes. While many of these changes are quite
ok and actually improve the code base a bit, they also generate a LOT
of traffic and discussion. This can be exhausting, especially if you
have to care about other things. So yes, it's all kind of noisy and
annoying. Sorry.

This doesn't mean you should go away, or that we don't want you, or
that you should stop doing what you do. On the opposite, I think you're
a promising new developer, and you should definitely stay.

Maybe you should feel encouraged to get on the next level. For example,
you could enter the fuzzing-security-bugs business, or the
rewrite-inline-asm-as-yasm business. Or pick anything that looks
interesting to you; you already have enough experience with this project
that you will find your way. You will learn new useful things, and the
result will be useful for everyone. It should also be more fun than
fixing theoretical standards issues.

> 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?

Important is fixing bugs that actually could affect people right now.
I do agree that ffmpeg should follow standards, and that code assuming
sizeof(int)==4 is buggy and should be fixed. But is it important enough
that we should go and turn around every single line of code? Or,
alternatively, depend on an ancient compiler, and work through
potentially hundreds of FATE failures? And only because someone _could_
decide that new architectures will use 64 bit ints? I don't think so.

The likeliness of this happening is very low anyway. Just look at
Windows: they decided that even the "long" type should remain 32 bit,
because making it 64 bit (like on Unix) would break way too much code.
The most likely scenario is that a 128 bit architecture will have the
same types and sizes as 64 bit systems, just with size_t/ptrdiff_t
being 128 bit, and a new "long long long int" type (I swear, they will
do it, even if that type name looks horrible).


More information about the ffmpeg-devel mailing list