The log functions are used in two places in the source code and nowhere else. libmowgli-2 has its own logging functionality. Logging is very much out-of-place for an IRC library.

irc_message_t currently works with null-terminated strings. While this is perfectly acceptable for IRC clients (sane servers should NEVER send messages with NULL bytes in them), IRC servers cannot make these same assumptions, as clients connections cannot reasonably be expected to send well-formatted data.

This is a potential memory leak and could lead to strange bugs if the server sends two JOINs for a user but only one PART. (While it is not likely that any stable IRCd would ever do anything along these lines, it is not impossible, and libunicorn should be able to handle such server-side bugs gracefully).

An array of string parameters is well-suited for IRC, but void pointers or an array of void pointers is much more flexible.

Buffering is a mess right now. It's easy to forget that code modifies and references a specific character buffer rather than copying data somewhere else in memory. This means that character buffers cannot be reused while an irc_message_t is still understood to be valid. In addition, the behavior of calling irc_message_format() with the same character buffer as is being used for the irc_message_t is too dependent on the inner workings of irc_message_format() for any sort of standard expected result to be determined. Typical use of the message API results in one character buffer being allocated for each message.

This fix will officialize the "one buffer per irc_message_t" design and hopefully result in cleaner and simpler code when using the message API.

This will probably be renamed to irc_message_sender_t or irc_message_source_t. Senders only make sense in the context of messages. The information that the irc_sender_t struct provides is not separate enough from irc_message_t to provide any sort of real reason to keep them separate.

In addition, I could not think of an effective way to keep the sender and message parser/formatters separate. While the same sender may show up over and over again, the message sender is still a property of the message. Thus it makes perfect sense to include sender parser/formatters as part of message.c.

Add functions to parse the 005 numeric (ISUPPORT) into an easily-usable data structure for clients.

The hardest thing to determine will how best to store the data. One solution might be to store the data in some sort of associative array, but as the same kinds of data will be stored over and over again, it might be better to store it in a struct containing fields for each possible ISUPPORT field.

My current thought is to cherry-pick ISUPPORT fields that will be important to nearly every IRC client, while ignoring the more obscure or less useful fields. The issue will then become to determine which fields are important enough to be included in libunicorn

While adding a user to a channel is very fast (O(1)), finding/removing users is unfairly slow (worst case O(n) where n is the number of users in the channel).

Functionality to keep track of other users on the network. This includes nicknames, away statuses, and the channels they are in. This should reduce the amount of memory used by the channel tracking system.

A set of function pointers or a hook table could be very useful for writing IRC client applications. However, the messages themselves already serve as a sort of edge trigger.

If an error occurs in the libunicorn client code but the parent code processes the message anyway, a state desync occurs. For example, if the client code attempts to create new channel objects in response to a JOIN message but fails for some reason, parent code that ignores error conditions will process the JOIN as if everything was successful. Hooks would only be called upon operation success, but a solution to this problem could also be solved through more robust error reporting.

An essential feature for any IRC client library.

Keep track of any important data for channels. This includes the topic, the users, and all channel modes, with or without flags. Mode tracking will depend heavily on ISUPPORT parsing.

The library is a semi-useless pile of source without some sort of build system

The client code does a good job of keeping track of which peers are in sight, but does not do a very good job of distinguishing itself in RPL_NAMREPLY lists from other peers. It is treated as any other nick. While this could be a problem in some situations, it can also be useful.

Right now, the exact way in which this is handled is undefined and a potential source for bugs. (For example, with the current way the code works, no peer nick change event will be generated if the client changes nicks.) The exact behavior should be sorted out into something sensible.

Doing this would not produce much more overhead than the current system of hooking does.

irc_client_t currently keeps a patricia of peers. On deinitialization, the entire list of peers is first unref'd, and then each channel object is destroyed, leading to more unrefs. Because new peers are not first ref'd before being added to the peer patricia, each peer ends up with a refcount of -1, which leads to undefined behavior.

Track the complete state of a client on the IRC network. This includes the state of every channel the client is in and several facts about the user and the network.

The dictionary implementation is very poorly-written, but is functional. It could stand to be improved upon.

Although the 512-byte buffer is supposed to include the CRLF as well, it still seems as if the buffer should be able to hold 512 bytes. As of right now, because the buffer is expected to be null-terminated, it can only hold 511 bytes, although very few messages ever get that long.

This is very possibly related to Issue #14 as well.