My grasp is that "len < 0" will never occur at the point of condition
check[*]. Under this assumption, the other check (for errno != EAGAIN)
does not decide anything, only making the code more obfuscated.
Please note that there used to be some discrepancies around in the past,
notably see commit bd910f7e9de2d320f10a12cd9a3e7a26fb00083a.
[*] proof is left ... ok, below:
We consider CMAN_DISPATCH_ALL only as it is prerequisite to even get
further in the evaluation of the discussed condition.
1. we can get into the loop condition when processing a message from
the waitlist and "len" is then set to the lenght of such handled
1a. message is added to the waitlist only indirectly from within
cman_dispatch, but cman_dispatch may proceed a received
message this far only if it was indeed received OK
(this includes nonzero lenght indicated in the header part
[although this is not checked directly], which is exactly
the value set to "len" checked in the discussed condition)
1b. hence, "len" cannot be negative when we reach the condition
this way (effectively skipping final errno comparison)
2. we can get into the loop condition also after processing directly
received message, where "len" carries the return value of either
recv or read
2a. any case of negative-or-zero "len" is captured immediately
after setting it, always resulting in returning from call