| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The "simple singly-linked-list" library has been replaced with GLib's
GList and GQueue.
|
|
|
|
|
| |
When there are standardized headers, use these instead of the bloated
os_compat.h.
|
|
|
|
| |
The usual bunch of pointer arguments which should be const.
|
|
|
|
|
|
|
|
|
| |
Try to only include headers which are really needed. We should
particularly check all "headers including other headers". The
long-term goal is to have a manageable, small API for plugins
(decoders, output) without so many mpd internals cluttering the
namespace.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7319 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will make refactoring features easier, especially now that
pthreads support and larger refactorings are on the horizon.
Hopefully, this will make porting to other platforms (even
non-UNIX-like ones for masochists) easier, too.
os_compat.h will house all the #includes for system headers
considered to be the "core" of MPD. Headers for optional
features will be left to individual source files.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7130 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@5834 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm checking for zero-size allocations and assert()-ing them,
so we can more easily get backtraces and debug problems, but we'll
also allow -DNDEBUG people to live on the edge if they wish.
We do not rely on errno when checking for OOM errors because
some implementations of malloc do not set it, and malloc
is commonly overridden by userspace wrappers.
I've spent some time looking through the source and didn't find any
obvious places where we would explicitly allocate 0 bytes, so we
shouldn't trip any of those assertions.
We also avoid allocating zero bytes because C libraries don't
handle this consistently (some return NULL, some not); and it's
dangerous either way.
git-svn-id: https://svn.musicpd.org/mpd/trunk@4690 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@4497 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@4489 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
The myfprintf bugs that are fixed here were NOT introduced in the
last patch, it's just that the stricter warning checks from moving
to fprintf caused string format bugs to actually be checked by gcc
git-svn-id: https://svn.musicpd.org/mpd/trunk@4484 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This patch massively reduces the amount of heap allocations at
the interface/command layer. Most commands with minimal output
should not allocate memory from the heap at all. Things like
repeatedly polling status, currentsong, and volume changes
should be faster as a result, and more importantly, not a source
of memory fragmentation.
These changes should be safe in that there's no way for a
remote-client to corrupt memory or otherwise do bad stuff to
MPD, but an extra set of eyes to review would be good. Of
course there's never any warranty :)
No longer do we use FILE * structures in the interface, which means
we don't have to allocate any new memory for most connections.
Now, before you go on about losing the buffering that FILE *
+implies+, remember that myfprintf() never took advantage of
any of the stdio buffering features.
To reduce the diff and make bugs easier to spot in the diff,
I've kept myfprintf in places where we write to files (and not
network interfaces). Expect myfprintf to go away entirely soon
(we'll use fprintf for writing regular files).
git-svn-id: https://svn.musicpd.org/mpd/trunk@4483 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|