Commit Graph

15 Commits

Author SHA1 Message Date
wm4 56c4cdf369 ta: add another array helper macro
Stupid C.
2015-06-01 01:35:56 +02:00
wm4 16a5c6c535 ta: memcpy(ptr, NULL, 0) is undefined 2015-03-23 18:03:45 +01:00
Ben Boeckel 2bbad06bfc ta: rename MP_TALLOC_ELEMS to MP_TALLOC_AVAIL
The macro actually returns the *available* space in the array, not how
much is actually filled in.
2015-01-27 18:09:36 +01:00
wm4 85fb2af369 Remove some superfluous NULL checks
In all of these situations, NULL is logically not allowed, making the
checks redundant.

Coverity complained about accessing the pointers before checking them
for NULL later.
2014-11-21 05:18:09 +01:00
wm4 be0896c173 ta/README: fix typos 2014-10-13 18:56:42 +02:00
Kevin Mitchell b11fdeab9e talloc README: more human readible api reference 2014-04-13 18:03:01 +02:00
wm4 82648ff229 ta: fix comment
If this function could return the input value (i.e. the == case was
correct), then macros like MP_GROW_ARRAY would have been incorrect. The
implementation was correct though, so there's no bug.
2014-02-23 16:51:00 +01:00
wm4 7dae316d50 ta: clarify a corner case 2014-02-23 16:50:51 +01:00
wm4 2cad237f8b ta: check overflow in array realloc macros 2014-01-02 23:54:59 +01:00
wm4 b4aa39a817 ta: fix compilation with NDEBUG 2013-12-19 21:27:02 +01:00
wm4 73a5417950 Merge mp_talloc.h into ta/ta_talloc.h 2013-12-17 02:18:16 +01:00
wm4 801ff8319f ta: fix typo in comment 2013-11-20 18:13:05 +01:00
wm4 81c602c7d2 ta: re-add MinGW cargo culting
Not really cargo cult, but an unexplainable, needless difference that
just exists to annoy us.

Fixes that gcc on MinGW treats format specifiers in MSVC mode. Just why?
Why?
2013-11-02 15:20:53 +01:00
wm4 03ec49be8f ta: track location debug info in 2 more cases
Was overlooked.
2013-10-30 22:19:32 +01:00
wm4 0933f12d28 Replace talloc
There are multiple reasons to do this. One big reason is the license:
talloc is LGPLv3+, which forces mpv to be licensed as GPLv3+.

Another one is that our talloc copy contains modifications, which makes
it essentially incompatible with upstream talloc (in particular, our
version aborts on out of memory conditions - well, it wasn't my idea).
Updating from upstream is also a bit involved - the talloc source is
not really organized in a way to allow copying it into projects (and
this isn't an intended use-case).

Finally, talloc is kind of big and bloated. The replacement halves the
amount of code - mainly because we didn't use all talloc features. It's
even more extreme if you compare upstream talloc (~4700 lines) and the
new allocator without talloc compat (~900 lines).

The replacement provides all features we need. It also doesn't clash
with talloc. (The talloc compatibility wrapper uses macros to avoid
introducing linker-level symbols which could clash with libtalloc.)

It also tries to lower the overhead (only 4 words opposed to 10 words
in talloc for leaf nodes in release mode). Debugging features like leak
reporting can be enabled at compile time and add somewhat more overhead.
Though I'm not sure whether the overhead reduction was actually
successful: allocations with children need an "extra" header, which adds
plenty of overhead, and it turns out that almost half of all allocations
have children. Maybe the implementation could be simplified and the
extra header removed - even then, overhead would be lower than talloc's.

Currently, debugging features can be entirely deactivated by defining
NDEBUG - I'm not sure if anything defines this directly yet, though.

Unlike in talloc, the leak reporting stuff is thread-safe. (That's also
why it's far less elegant, and requires extra list pointers.)

Comes with a compatibility layer, so no changes to mpv source code
are needed. The idea is that we will pretend to be using talloc for
a while, so that we can revert to our old talloc implementation at
any time for debugging purposes.

Some inspiration was taken from Mesa's ralloc:

    http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ralloc.h

This is another talloc replacement, but lacks some features we need
(getting size of an allocation, debugging features, being able to
access children in the dtor).

There's some information in ta/README what will happen next and how the
transition is expected to progress.
2013-10-13 01:36:09 +02:00