[vlc-devel] [PATCH] fix lfind errors on windows

Martell Malone martellmalone at gmail.com
Tue Nov 4 17:20:56 CET 2014

Your point here is very valid on the 4 cases.
Number 4 is actually the case being used on windows which is why I get an

I think a #define of the function that cast's it to unsigned int * in
mingw64 would be a good solution to cater for both cases.
I created a post on the mingw-w64 mailing list linking to this to see about
them accepting a commit of wrapper on their end.

Kindest Regards

On Tue, Nov 4, 2014 at 1:25 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:

> Le 2014-11-04 15:03, Martell Malone a écrit :
>> The issue here is there is nothing wrong with mingw-w64 as they link
>> to msvcrt
>> As defined here http://msdn.microsoft.com/en-us/library/a6xkkxfz.aspx
>> [3]
>> On little endian we can just ignore the warning but depending in the
>> strictness of the build / package system this is not an option.
> I can conceive four cases:
> 1) lfind() is inline,
> 2) lfind() is statically linked and LTO is active,
> 3) lfind() is statically linked but LTO is inactive,
> 4) lfidn() is dynamically linked.
> The pointer aliasing violation is only a potential problem in cases 1 and
> 2. But binary compatibility with the CRT is only a concern in case 4. And
> even then, a small wrapper that converts back-and-forth would not be hard.
> So I fail to see an excuse. I'm totally not merging that ugly ifdef hack.
> --
> Rémi Denis-Courmont
> _______________________________________________
> 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/20141104/7fc09214/attachment.html>

More information about the vlc-devel mailing list