[zeromq-dev] zmq_msg_init: suggest to change interface

john skaller skaller at users.sourceforge.net
Thu Jan 19 15:33:37 CET 2012

This interface:

int zmq_msg_init (zmq_msg_t *msg);

is really getting in my way. I have a "helper" function that
receives messages. This function is part of the Felix binding for zmq.

It has to create a message, initialise it,
do the receive, close the message, and return the result, which is a pair:

bytes_read, string

where bytes_read can be -1 to indicate an error.

The problem is, I cannot implement this helper function
because I do not know what to do with the error code
returned by zmq_msg_init. Only the application can know.
[It's the same with zmq_msg_close]

Of course I *could* return it. But it seems wrong.

zmq_msg_init cannot fail. It has to initialise a structure full of
random bytes, so there is no possible test for an error condition.
AFAIK it can't run out of memory or anything either.

So I'd like to suggest changing the interface to:

void zmq_msg_init (zmq_msg_t *msg);

In addition, I guess (??) a message initialised with this function 
can be re-initialised by one of the (other) initialisations functions,
since it doesn't do anything except set some variables, so there
are no resources to lose on a re-initialisation. So that should
be explicitly permitted.

As above, the other init function cannot check if they're
improperly called, and if one is called on an object initialised
by zmq_msg_init, no harm is done.

Contrarily, in my system, and at least in C++ as well, the "constructor"
could automatically call zmq_msg_init, which makes the object
immediately usable in some contexts, and still allows re-initialisation.
In these systems enforced initialisation is a good thing even though
there is a small overhead, because it allows subsequent improper
uses by say send or whatever to fail gracefully instead of corrupting

** CAVEAT: of course it IS possible to check if initialisations are
done more than once. The way to do it is to keep a list of
initialised objects externally. You can then dynamically
enforce proper usage of all the functions. I am NOT suggesting
this (although it might be useful for debugging!).

I use this technique in Felix to track the run time type of various
objects non-invasively for the garbage collector (using a JudyL
array that maps pointers to RTTI objects).

john skaller
skaller at users.sourceforge.net

More information about the zeromq-dev mailing list