[FFmpeg-devel] Proposal on clearly delineating nonC99 code in FFmpeg

[Roman Shaposhnik]

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
two phases: 
   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

Thanks,
Roman.