cURL / Mailing Lists / curl-library / Single Mail



From: Daniel Stenberg <>
Date: Mon, 13 Apr 2015 16:10:56 +0200 (CEST)

On Mon, 6 Apr 2015, mm.w wrote:

> it is only a suggestion here to keep a compatibility layer to be able to
> read from file but not be stuck with a ASCII file path [[or other 8bits
> which should rest in the museum of encodings]] ; windows does not support
> UTF-8 file path then the only solution is to use wfopen [even if the program
> internally uses UTF-8 literals] you can safely translate to UTF-16 then
> handling "wide" path ; feeding an fp to the interface instead of a file-path
> ; gives you the opportunity to stay away from this matter.

Okay thanks that clarified it for me. So you propose two changes: one that
changes the API to use file pointers instead of file names, and a second that
allows the program to pass in certs or keys in memory. I think it makes sense
to discuss them separately.

Also worth considering: opening a FILE * in a process and handing it over to a
DLL doesn't work on windows, see FAQ 5.5, so we'd get another windows-specific
problem in our lap instead of the current one. I'm not convinced that is a net

Do you have any proposed patches, ideas or anything on how to introduce
certs/keys in memory in a way that isn't specific to a particular TLS backend?

List admin:
Received on 2015-04-13