aboutsummaryrefslogtreecommitdiffhomepage
path: root/misc
Commit message (Collapse)AuthorAge
* bstr: fix possible undefined behavior with length 0 stringsGravatar wm42015-01-12
| | | | | | | | | | BSTR_P() passes the string length and start pointer to printf-like functions. If the lenfth is 0, the pointer can be NULL, but we're actually still not allowed to pass a NULL pointer in any case. This is mostly a technically, because nobody in their right mind would attempt to specifically break such cases. But it's still undefined behavior, and some libcs might be strict about this.
* Silence some Coverity warningsGravatar wm42014-11-21
| | | | None of this really matters.
* bstr: don't call memcpy(..., NULL, 0)Gravatar wm42014-11-21
| | | | | | This is clearly not allowed, although it's not a problem on most libcs. Found by Coverity.
* json: handle >\\"< fragments correctlyGravatar wm42014-10-21
| | | | | | It assumed that any >\"< sequence was an escape for >"<, but that is not the case with JSON such as >{"ducks":"\\"}<. In this case, the second >\< is obviously not starting an escape.
* lua: expose JSON parserGravatar wm42014-10-19
| | | | | | | The JSON parser was introduced for the IPC protocol, but I guess it's useful here too. The motivation for this commit is the same as with 8e4fa5fc (again).
* misc: add JSON parserGravatar wm42014-10-17
|
* bstr: check strings before memcmp/strncasecmpGravatar James Ross-Gowan2014-10-07
| | | | | | | | | bstr.start can be NULL when bstr.len is 0, so don't call memcmp or strncasecmp if that's the case. Passing NULL to string functions is invalid C, even when the length is 0, and it causes Windows to raise an invalid parameter error. Should fix #1155
* Move compat/ and bstr/ directory contents somewhere elseGravatar wm42014-08-29
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* Add Plan 9-style barriersGravatar wm42014-07-26
| | | | | | | | | | | | | | | | | | | | | | | Plan 9 has a very interesting synchronization mechanism, the rendezvous() call. A good property of this is that you don't need to explicitly initialize and destroy a barrier object, unlike as with e.g. POSIX barriers (which are mandatory to begin with). Upon "meeting", they can exchange a value. This mechanism will be nice to synchronize certain stages of initialization between threads in the following commit. Unlike Plan 9 rendezvous(), this is not implemented with a hashtable, because that would require additional effort (especially if you want to make it actually scele). Unlike the Plan 9 variant, we use intptr_t instead of void* as type for the value, because I expect that we will be mostly passing a status code as value and not a pointer. Converting an integer to void* requires two cast (because the integer needs to be intptr_t), the other way around it's only one cast. We don't particularly care about performance in this case either. It's simply not important for our use-case. So a simple linked list is used for waiters, and on wakeup, all waiters are temporarily woken up.
* sub: add detection via BOMGravatar wm42014-07-22
| | | | | | | | | | | Useful for Windows stuff. Actually, ENCA support should catch this, but, well, whatever, everyone seems to hate ENCA. Detection with BOM is trivial, although it needs some hackery to integrate it with the existing autodetection support. For one, change the default value of --sub-codepage to make this easier. Probably fixes issue #937 (the second part).
* build: include <strings.h> for strcasecmp()Gravatar wm42014-07-10
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* Audit and replace all ctype.h usesGravatar wm42014-07-01
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* ring: use a different type for read/write pointersGravatar wm42014-05-30
| | | | | | uint_least32_t could be larger than uint32_t, so the return values of mp_ring_get_wpos/rpos must be adjusted. Actually just use unsigned long as type instead, because that is less awkward than uint_least32_t.
* ring: implement drain in terms of readGravatar wm42014-05-29
| | | | | I think this makes it easier to reason about it and avoids duplicate logic.
* Fix gcc 4.7 warning about shadowing talloc_parent in mp_dispact_queueGravatar Paweł Forysiuk2014-05-28
|
* atomics: switch to C11 stdatomic.hGravatar wm42014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* threads: use mpv time for mpthread_cond_timedwait wrapperGravatar wm42014-05-18
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* dispatch: document some guaranteesGravatar wm42014-04-25
| | | | | | | | The here documented guarantee might simplify code using this mechanism a lot, because it becomes unnecessary to invent a separate mechanism to make the mp_dispatch_queue_process loop exit after processing a dispatch callback. (Instead, the dispatch callback can set a flag, and the caller of mp_dispatch_queue_process can check it.)
* dispatch: wakeup only if needed on mp_dispatch_resume()Gravatar wm42014-04-24
| | | | | | | | The wakeup is needed to make mp_dispatch_queue_process() return if suspension is not needed anymore - which is only the case when the request count reaches 0. The assertion added with this commit always has/had to be true.
* dispatch: improve documentation commentsGravatar wm42014-04-23
|
* threads: fix function nameGravatar wm42014-04-23
| | | | Closer to the corresponding standard function pthread_cond_timedwait.
* dispatch: implement timeoutGravatar wm42014-04-23
| | | | | | | | | | | | | Note that this mechanism is similarly "unreliable" as for example pthread_cond_timedwait(). Trying to target the exact wait time will just make it more complex. The main use case for this is for threads which either use the dispatch centrally and want mp_dispatch_queue_process to do a blocking wait for new work, or threads which have to implement timers. For the former, anything is fine, as long as they don't have to do active waiting for new works. For the former, callers are better off recalculating their deadline after every call.
* dispatch: use a real lock for mp_dispatch_lock()Gravatar wm42014-04-23
| | | | | | | | | | | This is much simpler, leaves fairness isues etc. to the operating system, and will work better with threading-related debugging tools. The "trick" to this is that the lock can be acquired and held only while the queue is in suspend mode. This way we don't need to make sure the lock is held outside of mp_dispatch_queue_process, which would be quite messy to get right, because it would have to be in locked state by default.
* dispatch: fix broken lockingGravatar wm42014-04-23
| | | | | | | | | | | | | | mp_dispatch_queue_process() releases the queue->lock mutex while processing a dispatch callback. But this allowed mp_dispatch_lock() to grab the "logical" lock represented by queue->locked. Grabbing the logical lock is not a problem in itself, but it can't be allowed to happen while the callback is still running. Fix this by claiming the logical lock while the dispatch callback is processed. Also make sure that the thread calling mp_dispatch_lock() is woken up properly. Fortunately, this didn't matter, because the locking function is unused.
* dispatch: wakeup target thread when locking/suspendingGravatar wm42014-04-23
| | | | | Without this, it could happen that both the caller thread and the target thread sleep.
* dispatch: move into its own source fileGravatar wm42014-04-23
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* charset_conv: mp_msg conversionsGravatar wm42013-12-21
|
* Split mpvcore/ into common/, misc/, bstr/Gravatar wm42013-12-17