On Tue, Mar 14, 2017 at 6:18 PM, wm4 <nfx...@googlemail.com> wrote: > >> Now back to the current issue. >> >> Do you agree with the fact that uint32_t is a better technical choice? >> (I think the main argument is that it's a pain to have proper FATE >> coverage if you don't?) > > We've already established that the current way FATE is doing it is not > a good idea. It relies on C ABI coincidences. It's equivalent to > parsing file formats by using read() calls with pointers to structs. > For example, big endian fate instances should be failing on side data > represented by structs (but apparently we don't test side data contents > anyway, only their size, which makes this whole side data discussion > even more ridiculous). >
We test the content, but it gets read as a struct and printed member by member, not byte-dumped, so endianness doesn't change the result. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
