This is indeed the one I am most concerned about. One possibility to reduce the potential impact would be to move the condition down a few lines so it affects only Win32 users, though in theory a URI constructed as "file:// /" with a space after the double-slash should always return null.<div>
<br></div><div>My concern is that this is used in at least some parts of the code as a quick-and-dirty method. I'm fine if it's not applied at all. It is, however, what put me on the trail of this to begin with -- when I noticed the different behavior under Win32 and Linux.</div>
<div><br><br><div class="gmail_quote">On Fri, Mar 16, 2012 at 9:50 AM,  <span dir="ltr"><<a href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 16 Mar 2012 10:38:03 +0200<br>
From: " R?mi Denis-Courmont" <<a href="mailto:remi@remlab.net">remi@remlab.net</a>><br>
To: <a href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>
Subject: Re: [vlc-devel] [PATCH 1/3] text: make_path returns (null) if<br>
        hostname starts with blank<br>
Message-ID: <<a href="mailto:201203161038.06327.remi@remlab.net">201203161038.06327.remi@remlab.net</a>><br>
Content-Type: Text/Plain;  charset="iso-8859-1"<br>
<br>
Le jeudi 15 mars 2012 22:54:27 John Freed, vous avez ?crit :<br>
> This makes Win32 conform to Linux behavior, as well as RFCs. Valid UNC<br>
> paths still work.<br>
<br>
I think this deserves a new test case in src/test/url.c.<br>
<br>
--<br>
R?mi Denis-Courmont<br>
<a href="http://www.remlab.net/" target="_blank">http://www.remlab.net/</a><br>
<a href="http://fi.linkedin.com/in/remidenis" target="_blank">http://fi.linkedin.com/in/remidenis</a><br>
<br><br></blockquote></div></div>