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
win.

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?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html