Hello,

1- yes DLL boundaries an zillion CRT I forgot about that ; could be solved
either passing a struct holding a read callback ; like this the symbol call
stays in the end of the caller or interfacing a function taking on win, a
wchar * t array for path then calling _wfopen which is not really elegant
as personally I don't like asymmetric APIs in a library.

struct curl_file_rb
{
    FILE * fp;
    .fread -> pass func pointer on build

    size_t read(void * ptr, size_t size, size_t nitems) {}

}

struct curl_file_wb
{
       FILE * fp;
    .fwrite -> pass func pointer on build

    size_t write ...
}

inside the DLL curl_file_rb->read(void * ptr, size_t size, size_t nitems)

2 - for the in memory data ; the TLS backends I know have all an interface
taking mem-buff or file desc ; PEM or PKCS12 data ; if not all backend
support it ( I don't know all of them ) ; let's enumerate the different
cases and find a solution.

Best.

On Mon, Apr 13, 2015 at 7:10 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

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

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-04-13