cURL / Mailing Lists / curl-library / Single Mail



From: mm.w <>
Date: Mon, 13 Apr 2015 08:15:41 -0700


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.


On Mon, Apr 13, 2015 at 7:10 AM, Daniel Stenberg <> 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?
> --
> /
> -------------------------------------------------------------------
> List admin:
> Etiquette:

List admin:
Received on 2015-04-13