[FFmpeg-devel] stlport with ffmpeg: Issue with time_is_forbidden_due_to_security_issues

[Reimar Döffinger]

On Thu, Sep 13, 2012 at 08:59:41PM +0200, Michael Niedermayer wrote:
> On Thu, Sep 13, 2012 at 11:24:09AM -0700, Raymond Toy wrote:
> > On Wed, Sep 12, 2012 at 4:20 PM, Raymond Toy <rtoy at google.com> wrote:
> > 
> > >
> > > Thanks for the patch.  It seems the idea is right, but it's much more
> > > compilicated than that.  For example libavformat/mov.c includes avformat.h,
> > > which includes <time.h>.  And vp8.c includes vp8.h which includes
> > > <pthreads.h> and stlport pthreads.h includes <time.h>
> > >
> > > I can work on some patch to take care of this, but it seems that it would
> > > be pretty messy to have to move all of the various system includes buried
> > > in header files to the c files.  Some guidance on what would be acceptable
> > > would be helpful.
> > >
> > >
> > Ok, I've gone through and made a bare minimum patch that will allow ffmpeg
> > to work with stlport.  The patch basically removes <time.h> from a few
> > header files and adds #include <time.h> to the files that need it.  Also
> > pthreads.h is moved from a few places too.
> > 
> > It works for me with stlport (where I only build the codecs I need).  It
> > also works with ffmpeg itself and builds all of the programs.
> > 
> > If can provide the patch (about 500 lines) if anyone is interested.
> 
> I dont yet understand fully what you are actually trying to do ?
> the undef of time is a ffmpeg internal thing. It does not affect
> applications using the libs or ffmpeg.
> how do you get these C++ STL includes into ffmpegs internals ?

I suspect that installing stlport means its headers replace the system
headers, both C and C++ headers.
However it still doesn't add up, for gcc _STLP_HAS_INCLUDE_NEXT should
be set and this code never be reached, whereas other compilers should
use <../path/##header> which does not have that issue either (though gcc
does not accept that).
Their fallback code has quite obviously serious issues, if you search
for it you will see that e.g. defining a macro named X86 will break
their headers. Which I'd call simply utterly broken.
I still think it is generally of advantage if our internal.h stuff
wouldn't end up in system headers, but it is pure chance that it is
only that macro causing issues, so working around that specifically
seems of limited value to me now.