Hello, On Thu, Jan 25, 2007 at 06:34:54PM +1030, Yuri Vilmanis wrote: > I don't remotely expect that any of this patch will make it onto the > ffmpeg mainline, or even be considered by the ffmpeg developers, > partially due to the intention of 'the ffmpeg project' not to support > non-gcc compilers, but mainly due to the general ugliness of the patch Actually you are wrong. The second part (ugliness) is and always was the only reason to reject things. Which, regardless of standards, is why assuming that a working inttypes.h exists is the solution that wins hands down (for reference, MPlayer did this since loong times and even shipped with an inttypes.h - but it was such a basic implementation that nowadays doing this is considered harmful). Now most of what you say following is unfortunately irrelevant since ffmpeg is _not_ a C++ project, but a C one, and (almost?) all you say below refers to C++, those two have nothing to do with each other (or at least not much more that any other two random programming languages). And one comment: I really, really can't imagine your NaN comparisons are the best way. At least use uint64_t, that saves you one comparison (and 64 bit types are even supported in compilers for 8 bit microcontrollers, so I can't imagine there is any compiler lacking them). It probably is broken anyway though, since floating point and integer endianness can differ, so you might consider using some of the stuff from libavutil/intfloat_readwrite (in case you even care though *g*). Greetings, Reimar D?ffinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4