Hi,
Tanguy Fautre wrote:
A bit OT, but which part of the C standard says that all uninitialized
variables shall default to 0? The only zero initialization guarantee
of the C standard I know of is related to static variables (which MSVC
supports).
I'm pretty sure even GCC doesn't zero-initialize variables by default, e.g.
13:31|p...@tabu:~/acgt/webservices-svn> cat t.c
#include <stdio.h>
int main()
{
int i;
printf("%d\n", i);
}
13:38|p...@tabu:~/acgt/webservices-svn> gcc -o t -std=c99 t.c
13:38|p...@tabu:~/acgt/webservices-svn> ./t
134513588
If what you say about FFmpeg expected C behaviour is true, it sounds
to me that FFmpeg is relying on a non-standard extensions of GCC.
If you don’t mind, I’ll take your email as an opportunity to express
my biggest complain about the FFmpeg project: its portability.
On the current situation of FFmpeg on Windows, IMHO the FFmpeg dev
team has abslolutely no valid reasons for not making FFmpeg portable.
In fact, it looks like they took several decisions with the sole
purpose of making FFmpeg a GCC-only / MSVC-incompatible product.
Reading their rant about MSVC on the official website tends to confirm
that some of their choices are mainly motivated by anti-microsoft
political reasons rather than technical.
From the FFMPEG FAQ (http://ffmpeg.org/faq.html#SEC9)
"""
4.3 Is Microsoft Visual C++ supported?
No. Microsoft Visual C++ is not compliant to the C99 standard and does
not - among other things - support the inline assembly used in FFmpeg.
If you wish to use MSVC++ for your project then you can link the MSVC++
code with libav* as long as you compile the latter with a working C
compiler. For more information, see the Microsoft Visual C++
compatibility section in the FFmpeg documentation.
There have been efforts to make FFmpeg compatible with MSVC++ in the
past. However, they have all been rejected as too intrusive, especially
since MinGW does the job adequately. None of the core developers work
with MSVC++ and thus this item is low priority. Should you find the
silver bullet that solves this problem, feel free to shoot it at us.
We strongly recommend you to move over from MSVC++ to MinGW tools.
"""
The second paragraph is interesting, as it suggests that people have at
least tried in the past to get ffmpeg to be MSVC-compatible. But if they
made the decision to use C99 (which does have some nice additions
compared to the older C standards) then MSVC is indeed left in the rain :)
- They’ve chosen to rely on the C99 standard, which is not as widely
as supported as C89 and C++98. GCC is the only widely-used compiler
that comes close to having a full C99 support (followed by the Intel
compiler), but even GCC is still missing several features
(http://gcc.gnu.org/c99status.html). MSVC and Borland have little C99
support.
- They use the AT&T assembly syntax for x86/x86-64 assembly code
instead of using the Intel assembly syntax or Intel intrinsics.
These two decisions alone mean that one would have to rewrite most of
FFmpeg to get it compiling on any compiler that is not a GCC-clone.
While there is nothing close to FFmpeg on the market (open or closed
source), while I’m a huge supported of FFmpeg and related projects,
such poor decisions are ridicule from a software engineering point of
view and ultimately hurts FFmpeg.
Bottom line: I think the ffmpeg devs only care about Linux (and other
unices). Windows folks are more used to having libraries available in
binary form so it takes just one guy to build FFMPEG using MinGW and
make it available for the rest to use.
Paul
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
