<div dir="ltr">Hi,<div><br></div><div>The native representation for filepaths on Linux is char[] (i.e. raw bytes). withCString converts from String to char[] using the current locale, which doesn't always work (at least, it doesn't always do what you want). As long as everything is in the same locale, ideally UTF-8, then you'll be fine, but it's legitimate to have a file whose name is not legal UTF-8 even in a UTF-8 locale, and these will cause you problems.</div><div><br></div><div>(Minor, nitpicky bugbear: the native representation for filepaths on Windows is wchar_t[] which is interpreted as UTF-16 *where possible*, but there are also some legal filenames (e.g. "C:\\Temp\\\xd800") which are invalid as UTF-16)<br></div><div><br></div><div>I'm not familiar with soxlib specifically, but for opening a file on Windows named as a char[] I'm going to guess that the library ultimately ends up calling a so-called ANSI version of a function like CreateFileA, which accepts a char[] and converts it to wchar_t[] within the OS according to the current code page. withCString seems to look at the current code page when converting a String to a char[] too, but clearly something's not matching for you.</div><div><br></div><div>So a few things to check:</div><div><br></div><div>- does soxlib use the ANSI version, CreateFileA or similar?</div><div>- what code page does it think it's in?</div><div>- can you convert the troublesome filename to bytes in this code page by hand, and compare with what withCString is doing?</div><div>- can you convert these bytes to wchar_t[] using <span style="color:rgb(0,0,0);font-family:Consolas,Courier,monospace;font-size:13px;line-height:17.5499992370605px">MultiByteToWideChar</span> in the current code page? Does this look like what you expect?</div><div><br></div><div>Unfortunately there's no complete general solution to this problem that fits through an API that only uses char[] for filenames - the mapping from filenames written as char[] to Windows filenames is never surjective. The best solution would be for soxlib to offer an API that accepted wchar_t[] filenames on Windows, although I appreciate this might not be reasonable!</div><div><br></div><div>Hopefully this helps a bit.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 July 2015 at 08:40, Malcolm Wallace <span dir="ltr"><<a href="mailto:malcolm.wallace@me.com" target="_blank">malcolm.wallace@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe the native representation for FilePaths on Windows should be UTF16 strings.<br>
<br>
Regards,<br>
Malcolm<br>
<span class=""><br>
> On 24 Jul 2015, at 22:52, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
><br>
><br>
> In my 'soxlib' package I have written a binding to<br>
><br>
> sox_format_t * sox_open_read(<br>
> char const * path,<br>
> sox_signalinfo_t const * signal,<br>
> sox_encodinginfo_t const * encoding,<br>
> char const * filetype);<br>
><br>
><br>
> I construct the C filepath "path" from a Haskell FilePath using Foreign.C.String.withCString. This works for ASCII and non-ASCII characters in Linux. However, non-ASCII characters let sox_open_read fail on Windows. What is the correct way to convert FilePath to "char *"?<br>
> _______________________________________________<br>
> Libraries mailing list<br>
</span>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>