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. In other words: I recall Nicolas mentioning that FFmpeg could do with using width specific types more liberally. If I see a patch which causes additional potential trouble if/when int's become 64 bits, I will raise the point. > > Plus Mark's point on technical possibility of it (thank GOD GCC didn't do > something as crazy as this on other platforms). Indeed, it is very fortunate that GCC does not do this on other platforms. That does not change whether we should test it or not. > > Timothy > _______________________________________________ > 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