On some platforms, g_free() must be used for memory allocated by
GLib.  This patch intends to correct a lot of occurrences, but is
probably not complete.

Merged casefolding code from two locations into this one library
function.

Changed the function prototypes to get locate_item_list objects
instead of num_items/items.

Instead of passing two parameters around (number of items, array of
items), combine both in a variable size struct.

Renamed functions and variables.

No CamelCase and no typedefs.

Pass const pointers where no writes are performed.

Don't use dbUtils.h functions.  This reduces 4 full database walks to
just one.

directory_is_root() is cheaper than
isRootDirectory(directory_get_path()).

Renamed all public functions, prefix is "spl_".

No CamelCase in file names.

string_toupper() and strDupToUpper() were not able to deal with
character sets other than US-ASCII.  Use GLib's g_utf8_casefold()
for strings.

Commit 0bfe7802 broke update for new files in the root directory,
because music_root->path was an empty string and not NULL.  There were
some NULL tests missing.  Change them to !isRootDirectory(path)
instead of path!=NULL.

CamelCase is ugly, rename the functions.

Yet another CamelCase removal patch.

Taming the directory.c monster, part II: move the database management
stuff to database.  directory.c should only contain code which works
on directory objects.

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