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

[Diego Biurrun]

On Tue, Mar 20, 2007 at 09:57:59PM -0500, Rich Felker wrote:
> On Wed, Mar 21, 2007 at 01:34:41AM +0100, Diego Biurrun wrote:
> > > > 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 ...
> 
> A header that declares open should NEVER be included in portable C
> code that's not posix-dependent. The conflict is actually nice because
> it reveals this coding mistake.

This is related to the problem at hand .. how?  What's the alternative?

> But I see you changed it anyway for no good reason...

I changed it for the reason I explained above, which is a perfectly good
and sensible reason to me.  Removing the unistd.h include fixes the
problem at hand, renaming open prevents the problem from cropping up
again.  Also, you specifically did not object, you just said you
preferred one solution over the other...

I became curious and looked at all the video filters, since they also
use open functions.  Lo and behold, vf_bmovl has renamed open to
af_open, vf_screenshot has renamed it to screenshot_open.  How this is
in any way better than using a single name that does not conflict is
beyond me.  Especially since - as we have witnessed for libaf - most
devs are likely to work around the problem with ugly hacks like
compiling all files with -D_IO_H ...

Diego