On Wed, 21 Oct 2015 06:00:21 -0400 Ganesh Ajjanagadde <[email protected]> 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). _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
