- 27 Aug, 2012 6 commits
-
-
Pieter Hintjens authored
Silence all "unused parameter" warnings from Clang.
-
Arthur O'Dwyer authored
-
Arthur O'Dwyer authored
This formerly unused parameter actually represents the socket on which the event was received. As such, we should check that its value makes sense: it must be either "rep" or "req", and in the case of some kinds of events, it must be specifically one or the other. After this change, "s" is no longer unused.
-
Arthur O'Dwyer authored
Compiling without warnings is a good goal, because it makes new warnings (which probably indicate bugs) stand out rather than getting lost in the spam. My fixes fall into two categories: - Adding (void) casts of unused parameters, where their unusedness seems like a TODO (or in some cases a bug?). - Removing parameter names altogether, where the function is clearly a stub that will never use its parameters. Should be no change in behavior.
-
Arthur O'Dwyer authored
char_traits<unsigned char>::to_char_type(x) used to return 0 no matter what x was, and likewise to_int_type(x) used to return 0 no matter what. (0 is what you get when you default-construct an integral type, which is what the old code was doing.) This seemed like buggy behavior to me, so I've changed it.
-
Pieter Hintjens authored
Fix build breaking typos in monitor VA code
-
- 26 Aug, 2012 6 commits
-
-
Ian Barber authored
Include a note about potential interactions with reactors, and update reference to old FAIL_UNROUTABLE name.
-
Ian Barber authored
The endpoint was excluding the tcp://, causing tests to fail
-
Ian Barber authored
Code as stands breaks shutdown process. It was a bugfix by Arthur to a bad line which was testing for an impossible state - but afaics we do actually want to flush in those states. It is possible I am wrong on that though - if there are any shutdown issues introduced aroudn this commit I would suggest further investigation around this flushing behavior.
-
Ian Barber authored
VA specific monitor event in socket base was named monitor_event rather than va_monitor_event
-
Ian Barber authored
The call to the va version of the function was using 'event' instead of 'event_'
-
Ian Barber authored
Compile was failing on the monitor_event function function due to the va_start params being switched.
-
- 25 Aug, 2012 1 commit
-
-
Pieter Hintjens authored
Various bugfixes found by compiling with extra warnings
-
- 24 Aug, 2012 5 commits
-
-
Arthur O'Dwyer authored
There are three versions of monitor_event(), all taking variadic arguments. The original code just has the first one creating a va_list and passing that va_list variadically to the second one... which creates a new va_list and passes it variadically to the third one... and of course everything blows up when we try to pull a non-va_list argument off the stack. The correct approach matches the C standard library's use of printf/vprintf, scanf/vscanf, and so on. Once you make a va_list, you must pass it only to functions which expect a va_list parameter.
-
Arthur O'Dwyer authored
Static analysis says: src\tcp_address.cpp(297): error V595: The 'res' pointer was utilized before it was verified against nullptr. Check lines: 297, 301. src\tcp_address.cpp(603): error V106: Implicit type conversion third argument 'full_bytes' of function 'memcmp' to memsize type. src\tcp_address.cpp(603): error V526: The 'memcmp' function returns 0 if corresponding buffers are equal. Consider examining the condition for mistakes. In fact the use of "memcmp" is correct, but the enclosing "if" isn't necessary, and the compiler is happier if "full_bytes" is a size_t.
-
Arthur O'Dwyer authored
Static analysis says: src\pipe.cpp(193): error V547: Expression is always false. Probably the '||' operator should be used here. If flush() is called on a pipe whose state was "terminated" or "double_terminated", the programmer's intent was to return immediately. But in fact the two conditions can never be true simultaneously, so the early return never happens, and we may try to flush a terminated pipe anyway.
-
Arthur O'Dwyer authored
Static analysis says: src\fd.hpp(38): error V103: Implicit type conversion from memsize to 32-bit type. Adding the explicit cast should shut it up.
-
Arthur O'Dwyer authored
Static analysis says: src\zmq.cpp(489): error V220: Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize. The value being casted: '* count_'. src\zmq.cpp(510): error V127: An overflow of the 32-bit 'nread' variable is possible inside a long cycle which utilizes a memsize-type loop counter. I've silenced the warning on line 489 and ignored the other. But also, it looks to me like there's a serious bug here: The out-parameter "count_" is never set to zero before we start incrementing it. So its final value will always be between 1 and 2 times its initial value. The fix seems obvious.
-
- 23 Aug, 2012 4 commits
-
-
Ian Barber authored
[LIBZMQ-414] Fix an error in the inline assembly for Thumb2.
-
Ian Barber authored
Fix a bug reported on the mailing list.
-
Arthur O'Dwyer authored
Both memcmp and strcmp return zero on equal, nonzero on nonequal; so all of these tests were backwards. The original committer fixed the failure by comparing 22 bytes instead of the correct 21, so that the assertions would trigger only if the 22nd byte happened to match exactly --- which was rare. The correct fix is to compare the right number of bytes with the right sense. (I think all of the ".addr" fields are null-terminated, in which case it's more appropriate to use strcmp throughout.)
-
Arthur O'Dwyer authored
Notice that ZeroMQ has never been compiled for Thumb2 before, and I personally don't make any guarantees that it will actually behave correctly once compiled. But after this patch, it is at least *possible* to compile it for Thumb2. (Thumb2 is the target for most iOS devices.)
-
- 12 Aug, 2012 1 commit
-
-
Pieter Hintjens authored
Exchange greeting messages for all socket types
-
- 11 Aug, 2012 1 commit
-
-
Martin Hurton authored
Fixes #415.
-
- 05 Aug, 2012 2 commits
-
-
Ian Barber authored
Revert zmq_poll NULL poll items check to 2.2 behavior - let the poll items count filter out empty poll sets and not return a sometimes unexpected EFAULT error status
-
Ian Barber authored
Fix reordering compile errors
-
- 04 Aug, 2012 3 commits
-
-
Sebastian Lauwers authored
-
Pieter Hintjens authored
Fix invalid address metadata for ZMQ_EVENT_DISCONNECTED
-
Lourens Naudé authored
-
- 31 Jul, 2012 2 commits
-
-
Ian Barber authored
Fix issue #406
-
Martin Hurton authored
When a peer reconnects, the router socket receives an identity message containing this peer id. When this happens, the current implementation crashes. This patch makes a router socket to silently ignore all identity messages coming from reconnected peers.
-
- 29 Jul, 2012 1 commit
-
-
Pieter Hintjens authored
Fix LIBZMQ-404: zmq_term not truly re-entrant
-
- 28 Jul, 2012 1 commit
-
-
Ricardo Catalinas Jiménez authored
zmq_term can not safely be re-entered with pgm transport. Fix proposed by Steven McCoy.
-
- 26 Jul, 2012 3 commits
-
-
Ian Barber authored
Correction for LIBZMQ-335
-
Matthew Metnetsky authored
That way it can be used more appropriately between processes.
-
Matthew Metnetsky authored
By assigning a SECURITY_DESCRIPTOR to the event we gain the ability to share it between service and console programs. We also added EVENT_MODIFY_STATE as a requirement to OpenEvent so we can SetEvent later in the method.
-
- 24 Jul, 2012 1 commit
-
-
Lourens Naudé authored
Revert zmq_poll NULL poll items check to 2.2 behavior - let the poll items count filter out empty poll sets and not return a sometimes unexpected EFAULT error status
-
- 18 Jul, 2012 1 commit
-
-
Pieter Hintjens authored
Small code cleanup
-
- 17 Jul, 2012 1 commit
-
-
Martin Hurton authored
-
- 13 Jul, 2012 1 commit
-
-
Ian Barber authored
Fix issue #397
-