| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I have absolutely no idea what the meaning of this value is or why it is
sometimes initialized to zero here, but doing this prevents some zero
division errors and thus makes some files play seemingly correctly.
|
|
I ran into a situation where one of these multiplications overflowed,
resulting in eventual memory corruption and similar fun things. Using
longs should mitigate the issue but may or may not actually fix it.
|
|
BouKiCHi seems to have deleted his repo. Fortunately, there's an
up-to-date fork.
|
|
|
|
|
|
I ran into a case where this 1024-entry buffer was indexed with 1388.
The chosen value for the buffer size is based on the following:
* In pcm8(), the parameter 'buffer_size' is used as the buffer's length.
* The source of that parameter ends up being 'len' in mdx_calc_sample(),
which in turn is at most '(data->mdx->dsp_speed * frame)/1000000'.
* 'dsp_speed' is a user-settable parameter defaulting to 44100; let's
assume that nobody will want to use a value greater than 192000 and
add a check in mdx_set_rate() just in case.
* 'frame' comes from mdx_parse_mml_get_tempo(). When 'self->mdx->tempo'
is 0 (I assume it can never be negative), the function computes the
maximum possible value: 65536.
Thus we get 65536 * 192000 / 1000000 = 12582.912, which we round up to
the next multiple of 1024 for some extra safety. Note that even with the
default 44100 we get 2890.1376 so the overflow was possible even without
using mdx_set_rate().
|
|
Plenty of internal symbols are exported, with rather generic names that
can (and do) conflict with other libraries. So link with -Bsymbolic,
which prevents overriding them with LD_PRELOAD but also prevents such
conflicts from causing problems with functions here accidentally calling
some other library's functions.
|
|
|
|
|
|
|
|
|
|
|