[MPlayer-dev-eng] MinGW hack in libaf/Makefile

[Diego Biurrun]

On Tue, Mar 20, 2007 at 10:39:59AM -0500, Rich Felker wrote:
> On Tue, Mar 20, 2007 at 10:38:59AM +0100, Diego Biurrun wrote:
> > > > It appears that on MinGW unistd.h includes io.h, which has a conflicting
> > > > declaration for open.  There are essentially two ways to fix this:
> > > > 
> > > > 1) Remove the #include <unistd.h>, it does not appear to be needed, at
> > > >    least on Linux.
> > > > 2) Rename open to af_open.
> > > > 
> > > > Probably doing both is the right solution.  Only one file (af_export.c)
> > > > appears to need unistd.h and there open has already been renamed to
> > > > af_open.
> > > > 
> > > > So unless there are any objections I'll go ahead and do that.
> > > 
> > > While I don't object (I prefer solution 1 but 1+2 is ok), it's wrong
> > > for unistd.h to define open at all. Only fcntl.h should define open.
> > > We should send bug reports upstream.
> > 
> > The problem is that one filter (af_export) includes fcntl.h.  There open
> > has been renamed to af_open already.  So we might as well be consistent.
> 
> IMO not. This is a very rare and special case (and probably one that
> should never have been added in the first place). No need to rename
> functions in tons of other files because a hackish special case
> requires it. Aside from af_export, all the filters are plain C code,
> not posix/unix-dependent stuff, so there's no reason they should avoid
> the posix function name open.

IMO it's more hackish to have one filter use a different name, besides
it's just too easy to have conflicts with a name like 'open'.  As soon
as one of the audio filters gets modified and includes a header where
open appears you're into this dance again.  I guess it's a matter of
taste ...

And yes, this hack (like so many others) should never have been added in
the first place ...

Diego