On Wed, Oct 21, 2015 at 5:31 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >> On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu <timothyg...@gmail.com> wrote: >>> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde <gajja...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel