[FFmpeg-devel] [PATCH 2/4] Define __EXTENSIONS__ to enable struct ip_mreq access on OpenSolaris.

[Roman V. Shaposhnik]

On Mon, 2009-01-05 at 22:34 +0100, Diego Biurrun wrote:
> On Mon, Sep 29, 2008 at 05:27:09PM -0700, Roman Shaposhnik wrote:
> > On Sun, 2008-09-28 at 23:01 +0200, Diego 'Flameeyes' Petten? wrote:
> > > "Roman V. Shaposhnik" <rvs at sun.com> writes:
> > > 
> > > > You shouldn't really tinker with __* stuff directly. IIRC, there's
> > > > a more standard way of enabling ip_mreq (something along the lines
> > > > of defining a proper combination of XPG* and POSIX version). I'd
> > > > be very surprised if __EXTENSIONS__ were the only way to get what
> > > > you want.
> > > 
> > > struct ip_mreq definition is protected by
> > > 
> > > #if !defined(_XPG4_2) || defined(__EXTENSIONS__)
> > 
> > This is weird. :-(
> > 
> > > Since FFmpeg builds with C99 and requires explicitly POSIX.1-2001
> > > (-D_POSIX_C_SOURCE=200112L), as soon as _XOPEN_SOURCE is defined,
> > > _XPG4_2 is also enabled; since there are a few cases where _XOPEN_SOURCE
> > > is used, and it might well be that more will be introduced, it seems to
> > > me the most solid option, to define __EXTENSIONS__, rather than relying
> > > on _XOPEN_SOURCE *not* being defined.
> > > 
> > > Of course if you have a better idea...
> > 
> > Let me look at it and talk to our POSIX/XPG "standard lawyers". It 
> > appears that defining __EXTENSIONS__ is, indeed, the only option.
> > But I still suspect that shouldn't be the case.
> 
> Roman, any results?

Some. On one hand, defining __EXTENSIONS__
is entirely legitimate way for asking 
features that are outside of most 
standards(5):
   http://docs.sun.com/app/docs/doc/819-2252/standards-5?a=view
----------------------------------------------
If the application is using interfaces and 
headers not defined by that standard, then 
in addition to defining the appropriate 
standard feature test macro, it must also 
define __EXTENSIONS__. Defining __EXTENSIONS__
provides the application with access to all
interfaces and headers not in conflict with 
the specified standard. The application must 
define __EXTENSIONS__ either on the compile 
command line or within the application source 
files.
----------------------------------------------

On the other hand, I still feel that it is
too big of a hammer to be used at the level
of -D__EXTENSIONS__

If I had my vote -- I'd rather carefully placed
   #define __EXTENSIONS__ 1 
in files where they are really called for.

Thanks,
Roman.