[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue
Thu Jan 25 12:38:02 CET 2007
On Thu, Jan 25, 2007 at 06:34:54PM +1030, Yuri Vilmanis wrote:
> Incidentally, FFMpeg uses the following C99 features which are marked as
> broken or missing in gcc (see http://gcc.gnu.org/c99status.html) (these
> I noted off-hand - there may be others):
i fear that the fact that ffmpeg works with gcc mostly invalidates your
claim that they are broken with gcc
> - inline functions - broken (very): symbol exporting behaviour is the
> exact opposite of the standard. Upshot is, anyone trying to use (compile
> or link to) ffmpeg with a C99 compiler would appear to be in for a nasty
> headache at link time (someone using a C99 compiler might like to
> comment on this?).
iam not aware of any bugreports about this, not to mention iam not aware
of any difference betweem gcc and C99 about "static inline" care to
elaborate on this? we dont use non static inline or extern inline or anything
like that ...
> The "inttypes.h" problem is not a MS Visual C++ problem, it's a problem
> with FFMpeg headers not being compatible with the ISO C++ standard. It
could you please also tell me which pascal and fortran rules we violate
no we really DONT support c++ in any way, if it happens to work then well
be happy, if some small and clean patch would help you that might be
considered for svn but beyond that i fear we cant help you
> If you really want to be that gnucentric,
do you know why everyone who uses visual <bluescreen, restarts system) C++
has a problem with understanding the different between standart and gcc?
we HATE gcc and we certainly are not, where not and never will be
gnucentric, ffmpeg code is stanard C, everything else is under #ifdefs
like asm, always_inline and so on
it must be something like
* user sees vc++ fail with random program
* user sees gcc to suceed with same random program
* user concludes that program is written specifically for gcc as he knows
MS always follows all standards very carefully
> you could wrap all your public
> headers in #ifdef __GNUC__ guards,
right after you wrap your head(er) in
> A third option is simply to drop support for C++ linkage - the 'pure C'
we NEVER did support that so how could we drop it?!
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel