Again, a data type which can be forward-declared.

The struct can be forward-declared by other headers, which relaxes the
header dependencies.

Being consistent with most UNIX functions...

This make argument order more consistent for iterators.
Additionally, these now return ssize_t results for error
checking.

Seeing the "mpd_" prefix _everywhere_ is mind-numbing as the
mind needs to retrain itself to skip over the first 4 tokens of
a type to get to its meaning.  So avoid having extra characters
on my terminal to make it easier to follow code at 2:30 am in
the morning.

Please report any new issues you may come across on Free
toolchains.  I realize how difficult it can be to build/maintain
cross-compiling toolchains and I have no intention of forcing
people to upgrade their toolchains to build mpd.

Tested with gcc 2.95.4 and and gcc 4.3.1 on x86-32.

tfing wrote:
> I have quite some files with an empty album tag as they do not come
> from a particular album.
>
> If I want to look for those files and browse them, this happens:
> :: nc localhost 6600
> OK MPD 0.12.0
> find album ""
> ACK [2@0] {find} too few arguments for "find"
>
> I'd like to be able to browse those files in a client like gmpc.
> So these 2 items would have to be developed:
> - list album should report that some files have an empty tag
> - it should be possible to search for an empty tag with the find command

Patch-by: Marc Pavot
ref: http://musicpd.org/mantis/view.php?id=464

Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list.  So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).

With a large music database, the linear string collection in
tagTracker.c becomes very slow.  We implemented that in a
quick'n'dirty fashion when we removed tree.c, and now we rewrite it
using the fast hashed string set.

Pass the client struct instead of the raw file descriptor.

Don't pass the raw file descriptor around.  This migration patch is
rather large, because all of the sources have inter dependencies - we
have to change all of them at the same time.

This patch continues the work of the previous patch: don't pass a file
descriptor at all to traverseAllIn().  Since this fd was only used to
report "directory not found" errors, we can easily move that check to
the caller.  This is a great relief, since it removes the dependency
on a client connection from a lot of enumeration functions.

Database traversal should be generic, and not bound to a client
connection.  This is the first step: no file descriptor for the
callback functions forEachSong() and forEachDir().  If a callback
needs the file descriptor, it has to be passed in the void*data
pointer somehow; some callbacks might need a new struct for passing
more than one parameter.  This might look a bit cumbersome right now,
but our goal is to have a clean API.

Return an "enum playlist_result" value instead of calling
commandError() in storedPlaylist.c.

The playlist library shouldn't talk to the client if possible.
Introduce the "enum playlist_result" type which the caller
(i.e. command.c) may use to generate an error message.

Move everything which dumps song information (via tag_print.c) to a
separate source file.  song_print.c gets code which writes song data
to the client; song_save.c is responsible for serializing songs from
the tag cache.

The usual bunch of const pointer conversions.

This prepares the following patches, which aim to reduce MPD's memory
usage: we plan to share tag_item instances, instead of just their
values.

Getting rid of CamelCase; not having typedefs also allows us to
forward-declare the structures.

Don't use CPP macros when you can use C enum... this also allows
better type checking.

Also enable -Wunused-parameter - this forces us to add the gcc
"unused" attribute to a lot of parameters (mostly library callback
functions), but it's worth it during code refactorizations.

Local variables which are never read before the first assignment don't
need initialization.  Saves a few bytes of text.  Also don't reset
variables which are never read until function return.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7199 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Instead of printing out the Id from playlist.c, instead set
the integer that added_id poitns to if added_id is non-NULL.

This makes the API cleaner and will allow us to use additional
commands to manipulate the newly-added song_id.  Callers
(handleAddId) that relied on printId to print it to the given
fd have now been modified to print the ID at a higher-level;
making playlist.c less-dependent on protocol details.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7149 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn-id: https://svn.musicpd.org/mpd/trunk@7143 09075e82-0dd4-0310-85a5-a0d7c8717e4f

new commands: playlistmove and playlistdelete.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6116 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@5952 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@5951 09075e82-0dd4-0310-85a5-a0d7c8717e4f

returning a list of matching songs, the number of results and total play
time of the results are returned.

git-svn-id: https://svn.musicpd.org/mpd/trunk@5950 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@5834 09075e82-0dd4-0310-85a5-a0d7c8717e4f

later be used for playlist searching.

git-svn-id: https://svn.musicpd.org/mpd/trunk@5419 09075e82-0dd4-0310-85a5-a0d7c8717e4f

compare the return value of getLocateTagItemType() to them.

git-svn-id: https://svn.musicpd.org/mpd/trunk@5138 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@5137 09075e82-0dd4-0310-85a5-a0d7c8717e4f

use of these functions are still being worked on.

git-svn-id: https://svn.musicpd.org/mpd/trunk@5075 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This behaves the same as: list filename

git-svn-id: https://svn.musicpd.org/mpd/trunk@4952 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@4605 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

Indent the entire tree, hopefully we can keep
it indented.

git-svn-id: https://svn.musicpd.org/mpd/trunk@4410 09075e82-0dd4-0310-85a5-a0d7c8717e4f

These are just warnings from sparse, but it makes the output
easier to read.  I ran this through a quick perl script, but
of course verified the output by looking at the diff and making
sure the thing still compiles.

here's the quick perl script I wrote to generate this patch:
----------- 8< -----------
use Tie::File;
defined(my $pid = open my $fh, '-|') or die $!;
if (!$pid) {
open STDERR, '>&STDOUT' or die $!;
exec 'sparse', @ARGV or die $!;
}
my $na = 'warning: non-ANSI function declaration of function';
while (<$fh>) {
print STDERR $_;
if (/^(.+?\.[ch]):(\d+):(\d+): $na '(\w+)'/o) {
my ($f, $l, $pos, $func) = ($1, $2, $3, $4);
$l--;
tie my @x, 'Tie::File', $f or die "$!: $f";
print '-', $x[$l], "\n";
$x[$l] =~ s/\b($func\s*)\(\s*\)/$1(void)/;
print '+', $x[$l], "\n";
untie @x;
}
}

git-svn-id: https://svn.musicpd.org/mpd/trunk@4378 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Functions that should stay inlined should have an explanation
attached to them.

git-svn-id: https://svn.musicpd.org/mpd/trunk@4355 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@4333 09075e82-0dd4-0310-85a5-a0d7c8717e4f