Proposal for an extended callbacks field

Sean Egan seanegan at
Thu Jul 26 20:15:15 EDT 2007

On 7/26/07, Gary Kramlich <grim at> wrote:
> Also, shoot me for mentioning this if it upsets you (and yes it's
> hacky), but there is absolutely NOTHING stopping anyone from declaring
> another static struct, and placing a pointer to it in the protocol data
> on the connection.  Of course that probably isn't optimal, but is
> another course.

I already mentioned this above as one of the possible solutions.

The best solution seems to be to simply continue adding members to the
struct as needed, reserving one of the reservedN fields for
sizeof(struct). Then, libpurple will use G_STRUCT_OFFSET to make sure
it's safe to dereference new callbacks before trying to call them.

This maintains type safety and adds no weird inconsistencies. It's
simple, straightforward, and this is what we'll do when needed.

It doesn't make sense to do this until it's needed, so it'll wait for
2.2.0 at earliest, but in the meantime, there's no need to worry about
using the prpl struct if (and only if) it's appropriate.

This is effectively a non-issue.


More information about the Devel mailing list