Commit Graph

4 Commits

Author SHA1 Message Date
Andreas Rheinhardt 790f793844 avutil/common: Don't auto-include mem.h
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.

Keep it for external users in order to not cause breakages.

Also improve the other headers a bit while just at it.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2024-03-31 00:08:43 +01:00
softworkz fee765c207 fftools/fopen_utf8: support long paths on Windows for fftools
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
2022-06-19 01:38:23 +03:00
Martin Storsjö 4cdc14aa95 libavutil: Deprecate av_fopen_utf8, provide an avpriv version
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 e743e7ae6e.

That mechanism doesn't work for external users, thus deprecate the
existing function.

Signed-off-by: Martin Storsjö <martin@martin.st>
2022-05-23 13:52:26 +03:00
Martin Storsjö 3fb9244642 fftools: Stop using av_fopen_utf8
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>
2022-05-23 13:35:59 +03:00