On Wed, Oct 21, 2015 at 6:18 AM, wm4 <nfx...@googlemail.com> wrote: > On Wed, 21 Oct 2015 06:00:21 -0400 > Ganesh Ajjanagadde <gajja...@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.
No problem - thanks for speaking up. > > 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. Got it. > >> 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. Ok, I will send patches if I see issues while working on some other thing, but not do a mass cleanup. Thanks. > > 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 > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
