summaryrefslogtreecommitdiff
path: root/fftools/fopen_utf8.h
Commit message (Collapse)AuthorAge
* fftools/fopen_utf8: support long paths on Windows for fftoolssoftworkz2022-06-19
| | | | | Signed-off-by: softworkz <softworkz@hotmail.com> Signed-off-by: Martin Storsjö <martin@martin.st>
* libavutil: Deprecate av_fopen_utf8, provide an avpriv versionMartin Storsjö2022-05-23
| | | | | | | | | | | | | | | | | | | | | | Since every DLL can use an individual CRT on Windows, having an exported function that opens a FILE* won't work if that FILE* is going to be used from a different DLL (or from user application code). Internally within the libraries, the issue can be worked around by duplicating the function in all libraries (this already happened implicitly because the function resided in file_open.c) and renaming the function to ff_fopen_utf8 (so that it doesn't end up exported from the DLLs) and duplicating it in all libraries that use it. This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in the exact same way as the existing avpriv_open / ff_open, with the same setup as introduced in e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65. That mechanism doesn't work for external users, thus deprecate the existing function. Signed-off-by: Martin Storsjö <martin@martin.st>
* fftools: Stop using av_fopen_utf8Martin Storsjö2022-05-23
Provide a header based inline reimplementation of it. Using av_fopen_utf8 doesn't work outside of the libraries when built with MSVC as shared libraries (in the default configuration, where each DLL gets a separate statically linked CRT). Signed-off-by: Martin Storsjö <martin@martin.st>