summaryrefslogtreecommitdiffstats
path: root/osdep/io.c
Commit message (Collapse)AuthorAgeFilesLines
* io: remove Windows tmpfile() emulationwm42019-09-191-35/+0
| | | | | | | | | | | | Unused now. The old stream cache used it, but it was removed. On a side note, the demuxer cache uses mp_mkostemps(). It looks like our Windows open() emulation handles this correctly by using CREATE_NEW, so no functionality gets lost by the "new" approach. On the other hand, the demuxer cache does not set FILE_FLAG_DELETE_ON_CLOSE, but instead tries to delete the file after opening (POSIX style), which probably won't work on Windows. But I'm not sure how to make it use the DELETE_ON_CLOSE flag, so whatever.
* osdep: add mkostemps() emulationwm42019-09-191-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supposed to follow the standard function. The standard function is not standard, but a GNU extension. Adding some ifdef mess is pointless too - it has no advantages other than having a mess, and not spotting implementation bugs in the emulation due to running it only on "obscure" platforms (like Windows, so most computers actually, except the developer's platform). There is mkstemp(), which at least is in POSIX 2008. But it's 100% useless, except in some obscure cases: it doesn't set O_CLOEXEC, nor can you pass it to it. Without O_CLOEXEC, we'd leak the temporary file to all child processes. (The fact that the file, which is expected to reach double or tripple digit GB sizes, will be deleted only once all processes unreference the FD, makes this sort of a big deal. You could ftruncate() it, but that doesn't fix all the other problems.) Why did POSIX standardize mkstemp() and O_CLOEXEC apparently at the same time, but provided no way to pass O_CLOEXEC to mkstemp()? With the introduction of O_CLOEXEC, they acknowledged that there's a need to atomically set the FD_CLOEXEC flag when creating file descriptors. (FD_CLOEXEC was standard before that, but setting it with fcntl() is racy.) You're much more likely to need a temp file that is CLOEXEC rather than the opposite, and even if they were somehow opposed to CLOEXEC by default (such as for compat. reasons), surely POSIX could have standardized mkostemp() too or instead. And then there's the fact that this whole O_CLOEXEC mess is stupid. Surely there would have been a better way to handle this, instead of requiring adding O_CLOEXEC to almost ALL instances of open() in all code that has been written ever. The justification for this is that the historic default was wrong, and you can't change it (e.g. this won't work: changing the behavior of exec() and not inherit the FD to the child process, unless a hypothetical O_KEEP_EXEC flag is set). But on the other hand, surely you could have introduced an exec() variant which does close all FDs, except a whitelist of FDs passed to it. Let's call it execve2(). In fact, I'm going to argue that exec() call sites are the most aware of whether (and which) FDs to inherit. Some programs even tried to explicitly iterate over all opened FDs and explicitly close "unwanted" FDs (which of course was problematic for other reasons), and such an execve2() call would have been the ideal solution. Maybe this proposed solution would have had problems too. But surely revisiting and reviewing every exec*() call would have been simpler than reviewing every open() call. And more importantly, having to extend every damn library function that either calls open() or creates FDs in some other way, like mkstemp(). What argument are there going to be against this? That there will be library code that can't keep working correctly with processes that use the "old" exec? Well, what about all my legacy library code that uses open() incorrectly, and that will break no matter what? Well, I'm not going to claim that I can come up with better solutions than POSIX (generally or in this case), but this situation is ABSOLUTELY ATROCIOUS. It makes win32 programming look attractive compared to POSIX, that standard pandering to dead people from the past. (Note: not trying to insult dead people.) I'm not sure what POSIX is even doing. Anything useful? Doesn't look like it to me. Are they paid? Why? They didn't even fix the locale mess, nor do they intend to. I bet they're proud of discussing compatibility to 70ies code day in and day out iwtohut ever producing anything useful. What a load of crap. They seriously got to do better than this. Oh, and my wrapper is probably buggy. Fortunately that doesn't matter. Also I'm dumping this into io.h. Originally, io.h was just supposed to replace broken implementation of standard functions by MinGW (and then by Android), but whatever, just give a dumping ground for shit code.
* win32: fix semantics of POSIX 2008 locale stubsJames Ross-Gowan2017-11-191-0/+14
| | | | | | | | | | | | | | | | | This sliences some warnings about unused values and statements with no effect, but it also fixes a logic error with freelocale(), since previously it would not work as expected when used in the body of an if statement without braces. Uses real functions, because with macros, I don't think there is a way to silence the "statement with no effect" warnings in the case where the return value of uselocale() is ignored. As for replacing the these functions with working implementations, I don't think this is possible for mpv's use-case, since MSVCRT does not support UTF-8 locales, or any locale with multibyte characters that are three or more bytes long. See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale
* win32: add more-POSIXy versions of open() and fstat()James Ross-Gowan2017-10-251-34/+281
| | | | | | | | | | | | | | Directory-opening never worked on Windows because MSVCRT's open() doesn't open directories and its fstat() doesn't recognise directory handles. These are just MSVCRT restrictions, and the Windows API itself has no problem with opening directories as file objects, so reimplement mpv's mp_open and mp_stat to use the Windows API directly. This should fix directory playback. This also populates the st_dev and st_ino fields of struct stat, so filesystem loop checking in demux_playlist.c should now work on Windows. Fixes #4711
* Universal Windows Plaform (UWP) supportPedro Pombeiro2017-06-291-2/+39
| | | | | | | | libmpv only. Some things are still missing. Heavily reworked. Signed-off-by: wm4 <wm4@nowhere>
* win32: fix mismatched free/talloc_freewm42017-04-121-1/+1
| | | | Might fix #4315.
* win32: rewrite getcwd() using GetFullPathNameWwm42017-04-111-2/+11
| | | | _wgetcwd is apparently not available in all runtimes. Well, whatever.
* win32: add UTF-8 getcwd() wrapperwm42017-04-111-0/+18
|
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-0/+8
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* win32: revert wchar_t changeswm42015-08-011-15/+15
| | | | | | | | | | | Revert "win32: more wchar_t -> WCHAR replacements" Revert "win32: replace wchar_t with WCHAR" Doing a "partial" port of this makes no sense anymore from my perspective. Revert the changes, as they're confusing without context, maintenance, and progress. These changes were a bit premature anyway, and might actually cause other issues (locale neutrality etc. as it was pointed out).
* win32: replace wchar_t with WCHARwm42015-07-291-15/+15
| | | | | | | | | | | | | WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context, using WCHAR instead is more portable. This affects only non-MinGW parts, so not all uses of wchar_t need to be changed. For example, terminal-win.c won't be used on Midipix at all. (Most of io.c won't either, so the search & replace here is more than necessary, but also not harmful.) (Midipix is not useable yet, so this is just preparation.)
* Update license headersMarcin Kurczewski2015-04-131-4/+6
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: use a platform-specific unicode entry-pointJames Ross-Gowan2015-04-111-26/+0
| | | | | | | | | | Add a platform-specific entry-point for Windows. This will allow some platform-specific initialization to be added without the need for ugly ifdeffery in main.c. As an immediate advantage, mpv can now use a unicode entry-point and convert the command line arguments to UTF-8 before passing them to mpv_main, so osdep_preinit can be simplified a little bit.
* win32: add mmap() emulationwm42014-12-261-0/+59
| | | | | | | | Makes all of overlay_add work on windows/mingw. Since we now don't explicitly check for mmap() anymore (it's always present), this also requires us to make af_export.c compile, but I haven't tested it.
* win32: silence some warningsJames Ross-Gowan2014-11-081-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* osdep: add helper for creating a sane pipe()wm42014-10-261-4/+20
| | | | | Or in other words, a pipe that has the CLOEXEC flag set. Needed since Linux' pipe2() is not in POSIX yet.
* win32: remove an unneeded mechanismwm42014-10-191-3/+1
| | | | | Instead of relying on the macro-defined lseek(), just use _lseeki64 directly, and avoid a minor mess.
* win32: get rid of mp_stat in the normal source codewm42014-10-171-2/+27
| | | | | | | | | | | mp_stat() instead of stat() was used in the normal code (i.e. even on Unix), because MinGW-w64 has an unbelievable macro-mess in place, which prevents solving this elegantly. Add some dirty workarounds to hide mp_stat() from the normal code properly. This now requires replacing all functions that use the struct stat type. This includes fstat, lstat, fstatat, and possibly others. (mpv currently uses stat and fstat only.)
* win32: make lseek() fail on pipeswm42014-10-171-0/+11
| | | | | | On MingGW seeking on pipes succeeds. This fix is quite similar to Gnulib's (lib/lseek.c).
* win32: add tmpfile() replacementJames Ross-Gowan2014-09-051-0/+35
| | | | | | | | | | | The Windows version of tmpfile is actually pretty broken. It tries to create the file in the root directory of the current drive, which means on Vista and up, it normally fails due to insufficient permissions. Replace it with a version that uses GetTempPath. Also remove the Windows-specific note about automatic deletion of the cache file. FILE_FLAG_DELETE_ON_CLOSE is available in NT, and it should be pretty reliable.
* win32: correct HANDLE typeJames Ross-Gowan2014-08-241-2/+2
| | | | | The correct type is HANDLE, not HANDLE*, though this change shouldn't affect functionality.
* win32: emulate some ANSI terminal escape codeswm42014-08-211-6/+4
| | | | | | | | | | | | | | We already redirect all terminal output through our own wrappers (for the sake of UTF-8), so we might as well use it to handle ANSI escape codes. This also changes behavior on UNIX: we don't retrieve some escape codes per terminfo anymore, and just hardcode them. Every terminal should understand them. The advantage is that we can pretend to have a real terminal in the normal player code, and Windows atrocities are locked away in glue code.
* osdep: don't assume errno is positivewm42014-07-251-2/+2
| | | | | Apparently this is not necessarily the case, so just drop the silly idea that depended on this assumption.
* input: separate wakeup pipe creation into a separate functionwm42014-05-301-0/+25
| | | | | Error handling is slightly reduced: we assume that setting a pipe to non-blocking can never fail.
* osdep: silence a -Wshadow warningwm42014-05-211-2/+2
|
* client API: add mpv_get_wakeup_pipe convenience functionwm42014-04-121-1/+1
| | | | Should make integreating with some event loops easier. Untested.
* io: make MP_PATH_MAX private to win32 codewm42014-02-031-0/+10
| | | | | The win32 code is the only thing which actually needs this (and it's used to make emulation of UTF-8 filename APIs easier).
* io/win32: move mp_attach_console to terminal-win.cMartin Herkt2014-01-161-22/+0
| | | | Why didn't I put it there from the start?
* Windows: use the GUI subsystem, attach to consoleMartin Herkt2014-01-021-0/+22
| | | | | | | | This is necessary to start mpv without forcing a console window, but also breaks console usability. A workaround is to call mpv from a wrapper process that uses the console subsystem and helps redirecting the standard streams and WriteConsole output to where they belong.
* osdep/io, mp_vfprintf: split out console detectionMartin Herkt2014-01-021-42/+43
|
* Merge mp_talloc.h into ta/ta_talloc.hwm42013-12-171-4/+2
|
* osdep/io: also include unistd.hwm42013-11-301-0/+2
| | | | Might be needed by fcntl() usage.
* Use O_CLOEXEC when creating FDswm42013-11-301-1/+17
| | | | | | | | | | | | | | This is needed so that new processes (created with fork+exec) don't inherit open files, which can be important for a number of reasons. Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux specific), we #define it to 0 in io.h to prevent compilation errors on older/crappy systems. At least this is the plan. input.c creates a pipe. For that, add a mp_set_cloexec() function (which is based on Weston's code in vo_wayland.c, but more correct). We could use pipe2() instead, but that is Linux specific. Technically, we have a race condition, but it won't matter.
* build: make pthreads mandatorywm42013-11-281-7/+0
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* osdep/io.c: include config.hwm42013-11-201-0/+2
| | | | | This possibly enables code that has never been tested before (accidentally), so let's hope this works out ok.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-2/+2
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* win32: add getenv() UTF-8 variantwm42013-09-181-0/+60
| | | | | | | This is a bit "hard", because getenv() returns a static string, and we can't just return an allocated string. We also want getenv() to be thread-safe if possible. (If the mpv core is going to be more threaded, we sure do want the lower layers to be thread-safe as well.)
* windows support: fix _wstat misusagewm42013-01-131-1/+1
| | | | | | | I have no idea when or how this broke, but _wstati64() is the function we want anyway (64 bit filesize). Possibly this was a mingw-w64 bug. It's unknown why "wstat()" just doesn't work in this case, as it's not defined by MSDN and could be defined by mingw as it needs.
* win32: use more unicode functionswm42012-04-061-5/+20
| | | | | | | | Use the *W variants instead of the implicit *A functions. (One could define the UNICODE macro to switch the functions without suffix from A to W, but I'm too lazy to figure out how portable that is, etc.) Also make sure io.h defines a unicode aware printf().
* windows: terminal: unicode, --msgcolor, size changeMartin Herkt2012-03-091-0/+58
| | | | | | | Make mp_msg() support unicode output, --msgcolor and variable screen sizes. Patch reintegrated by wm4.
* windows support: unicode filenameswm42012-03-091-0/+185
Windows uses a legacy codepage for char* / runtime functions accepting char *. Using UTF-8 as the codepage with setlocale() is explicitly forbidden. Work this around by overriding the MSVCRT functions with wrapper macros, that assume UTF-8 and use "proper" API calls like _wopen etc. to deal with unicode filenames. All code that uses standard functions that take or return filenames must now include osdep/io.h. stat() can't be overridden, because MinGW-w64 itself defines "stat" as a macro. Change code to use use mp_stat() instead. This is not perfectly clean, but still somewhat sane, and much better than littering the rest of the mplayer code with MinGW specific hacks. It's also a bit fragile, but that's actually little different from the previous situation. Also, MinGW is unlikely to ever include a nice way of dealing with this.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 15:17:14 +0000