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

Roman Shaposhnik rvs
Sun Jul 8 00:09:23 CEST 2007


this item has been on my TODO list for quite sometime and it has
to do with the constructs like this one (from libavutil/mem.h):

#ifdef __GNUC__
  #define DECLARE_ALIGNED(n,t,v)       t v __attribute__ ((aligned (n)))
  #define DECLARE_ALIGNED(n,t,v)      __declspec(align(n)) t v

The problem I have with the above is that we're not testing for the
right thing here. The fact that GCC is being used is irrelevant, since
all we really care about is whether compiler supports 'aligned'
attribute. But that's just the first layer this particular onion has.
The second one is the fact that whether GCC-style aligned attributes are
supported or not is also irrelevant. All we're looking for is ANY kind
of C99 language extension that would allow us to declare aligned 
variables (which by the way makes this particular case very broken for
any compiler that doesn't claim to be __GNUC__ but also doesn't happen
to be Microsoft Visual Studio).

So, in order to address the second issue I propose that we create 
a dedicated header file: ffmpeg/c99_extensions.h where all things
like DECLARE_ALIGNED would be declared. 

In order to address the first issue I propose that we don't test for
particular compilers even within the ffmpeg/c99_extensions.h but
we delegate the testing to ./configure script. So that ANY compiler
that supports, lets say, GCC-style attributes would be treated as
a first class citizen without resorting to bogus pre-defines of

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).


More information about the ffmpeg-devel mailing list