>>>>> I actually ended up solving it by removing all uses of BIO_new_fp() in >>>>> favor of my own custom BIO that I just finished writing earlier this >>>>> week. >>>> Why not BIO_new_file? >>> Yeah, I discovered while analyzing the code that using BIO_new_file() >>> rather than BIO_new_fp() would disengage applink, however that was not >>> an option for me because BIO_new_file() can't open a file whose name >>> contains non-ANSI Unicode characters on Windows. I have to open the >>> file myself using _wfopen(). >> There was suggestion to fall back to wfopen from a vmware engineer a >> while ago, but he couldn't provide patch (not that it would be very >> complex) and it was not followed up. Idea must have been something >> similar to just committed http://cvs.openssl.org/chngview?cn=19610. > why not adding the following to BIO_new_file()? > > - BIO interface still uses char * (meaning latin ASCII 0x20..0x7F)
This is incorrect assumption. BIO_new_file and fopen allow for characters recognized as valid in current locale, which is not necessarily limited to ASCII. In other words it's perfectly possible to BIO_new_file as well as to fopen file with international characters in its name, but the set of allowed non-ASCII characters varies. > - BIO implementation calls UTF8_to_UCS16() I.e. suggestion is to unconditionally assume UTF8 encoding of file name. It's not safe assumption (see above). > on all platforms supporting > wfopen or _wfopen What are the platforms supporting wfopen? Among those supported by OpenSSL? It's Windows platforms. > - BIO implementation then calls wfopen / _wfopen with this UCS16 value > (sometimes known as WCHAR*) > - For Win32 and Win32_WinCE the conversion can be done with > FormatMessage() API. It's allways available. ??? So as MultiByteToWideChar... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
