it is good that you added the additional error code, "cover all bases", as they say. In any case your exception handling will inform if something has been missed, should it occur.
So at the risk of triggering another MS curiosity, the changes look fine


On 21/09/2016 19:45, Rob McKenna wrote:
The link would be handy:


On 21/09/16 07:44, Rob McKenna wrote:
I've updated the webrev here with the copyright year (thanks Christoph) and 
extra error codes. I overlooked the codes from the old implementation of 
tcp_ping4 above this code. These are winsock error codes which I would expect 
IcmpSendEcho to use, but in our testing it actually returned the system error 
codes in at least one situation:


On 21/09/16 06:32, Seán Coffey wrote:
spotted an interesting blog on the MSDN timeout issue here :


On 21/09/16 17:42, Mark Sheppard wrote:
the IcmpSendEcho series of calls come with some idiosyncrasies in that
there is a minimum timeout that they can handle
think it is about 1000msecs. isReachable can specify a finer grained
timeout hence the need for timeout check


On 21/09/2016 17:18, Vyom Tewari wrote:
Hi Rob,

Do you really think this extra check is required ?

if (pEchoReply->Status == IP_SUCCESS
+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any
doc(MSDN) which explains this. I think in case of IP_SUCCESS
"RoundTripTime" is always less than timeout. I think similar changes is
required in Inet6Address.c as well ? Thanks, Vyom

On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote:
Hi folks,

I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* 
calls can actually return a similar set of errors regardless of whether the 
call itself failed or succeeded. This change checks that both the call and the 
ping were successful. In addition to that it takes a number of common failure 
causes into account before deciding to throw an exception.


Reply via email to