[vlc-devel] Several "mini include-guards" within `include/vlc_codecs.h`; rationale?

Filip Roséen filip at atch.se
Sat Feb 20 17:21:43 CET 2016


I cannot find any functionality that relies on the behavior previously
described, but in order to play it "better safe than sorry" - we could
patch each situation so that the result is as follows:

    #ifndef VLC__SKIP_VIDEOINFOHEADER
    #define VLC__SKIP_VIDEOINFOHEADER
    
    #ifdef _VIDEOINFOHEADER_
    #  warning "_VIDEOINFOHEADER_ is deprecated, use VLC__SKIP_VIDEOINFOHEADER"
    #else
    #  define _VIDEOINFOHEADER_

    typedef struct
    ATTR_PACKED
    {
        RECT32                  rcSource;
        RECT32                  rcTarget;
        uint32_t                dwBitRate;
        uint32_t                dwBitErrorRate;
        REFERENCE_TIME          AvgTimePerFrame;
        VLC_BITMAPINFOHEADER    bmiHeader;
    } VIDEOINFOHEADER;

    #endif
    #endif


The above means that the functionality is preserved (with an added
*warning*) while allowing developers time to move away from the
deprecated identifier.

When we are more comfortable removing `_VIDEOINFOHEADER_` (and the other
aprox. 9 cases in `include/vlc_codecs.h`), we simply remove the inner
branch from each of them.

  - What do you guys think?


On 16/02/20 11:10, Jean-Baptiste Kempf wrote:

> On 20 Feb, Filip Roséen wrote :
> > Questions
> > ---------
> > 
> >   - Are the weird "include-guards" in `include/vlc_codecs.h` documented
> >     behavior, or can they safely be removed (or atleast renamed to make
> >     the identifiers legal)?
> 
> In theory, they are not necessary.
> 
> In practice, it can be a bit more complex. Both of the examples you gave
> are Windows GDI, DShow, DX, MFT or related MS-video technologies.
> 
> The issue is that they are differently defined on various versions of
> Windows headers and MingW headers. And sometimes only partially.
> 
> And those defines were done, because the headers were defining those
> first, and safe-guarding with those exact defines.
> 
> I believe now they're probably unnecessary, but it needs to be
> extensively tested.
> 
> With my kindest regards,
> 
> -- 
> Jean-Baptiste Kempf
> http://www.jbkempf.com/ - +33 672 704 734
> Sent from my Electronic Device
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160220/5ea57dbd/attachment.html>


More information about the vlc-devel mailing list