[FFmpeg-devel] Proposal on clearly delineating nonC99 code in FFmpeg
Sun Jul 8 00:51:17 CEST 2007
On Sat, 2007-07-07 at 23:20 +0100, M?ns Rullg?rd wrote:
> It is fairly common to call such headers compiler.h, so perhaps we
> should follow suit.
That's a good suggestion. Personally I would like the name of the
file to communicate that it is a central place for all things nonC99,
but you are right -- most of the projects use compiler.h for
that very same purpose. I'm curious to hear what do others think?
> > I see this proposal giving us two crucial benefits:
> > * a centralized location for all things that break out of
> > C99 realm would make the job of anybody porting FFmpeg to
> > different platforms much easier. Of course, every construct
> > we put in this header file will be heavily commented explaining
> > what we expect it to do and giving hints on how it can be
> > ported to C99 platforms without direct support for it.
> > * testing whether a known feature actually works instead of
> > assuming that it always does if compiler is X and it always
> > doesn't if compiler happens to be Y is a much cleaner
> > approach for both cases (in fact I've seen GCC break some
> > of the lesser used attributes from time to time -- something
> > that won't get caught unless you actually test for the feature).
> Crafting a test that really determines whether something works is
> often less than trivial. What appears to work in a simple test case
> may well fail in obscure ways when used in real code. This
> notwithstanding, testing whether the constructs in question compile OK
> is certainly better than only testing a preprocessor definition.
Seems like we are in agreement (although I'm waiting for Michael
to chime in). Speaking of patches I would like to commit it in
1. create a header file but still have everything in it be based
on #ifdef __GNUC__ and such
2. update ./configure and the header file
More information about the ffmpeg-devel