Commit Graph

10 Commits

Author SHA1 Message Date
wm4 fafa2f4b85 osdep/io: also include unistd.h
Might be needed by fcntl() usage.
2013-11-30 23:17:20 +01:00
wm4 95cfe58e3d Use O_CLOEXEC when creating FDs
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.
2013-11-30 22:40:51 +01:00
wm4 0d255f07bf build: make pthreads mandatory
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.)
2013-11-28 19:28:38 +01:00
wm4 31fc48f0a8 osdep/io.c: include config.h
This possibly enables code that has never been tested before
(accidentally), so let's hope this works out ok.
2013-11-20 18:12:58 +01:00
Stefano Pigozzi 37388ebb0e configure: uniform the defines to #define HAVE_xxx (0|1)
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
2013-11-03 21:59:54 +01:00
wm4 12372298a2 win32: add getenv() UTF-8 variant
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.)
2013-09-18 19:08:51 +02:00
wm4 cbdee50f29 windows support: fix _wstat misusage
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.
2013-01-13 17:32:39 +01:00
wm4 a659429f86 win32: use more unicode functions
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().
2012-04-06 23:56:30 +02:00
Martin Herkt f891939b4d windows: terminal: unicode, --msgcolor, size change
Make mp_msg() support unicode output, --msgcolor and variable screen
sizes.

Patch reintegrated by wm4.
2012-03-09 20:48:54 +02:00
wm4 a1244111a7 windows support: unicode filenames
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.
2012-03-09 20:48:54 +02:00