[net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...)

[practicalswift]

In the case that the branch ...

if (itInFlight != mapBlocksInFlight.end() && itInFlight->second.first == nodeid) {

... is taken, there was prior to this commit an implicit assumption that MarkBlockAsInFlight(...) was being called with its fifth and optional argument (pit) being present (and non-NULL).

There are three calls to MarkBlockAsReceived(...) and for two of these the optional fifth argument is not supplied, which means that pit is being set to the default value of NULL.

This commit adds an assertion which makes the mentioned assumption explicit, and removes the possibility of a NULL pointer dereference.

[theuni]

I think this can be a static_assert

[practicalswift]

@theuni But static_assert(…) would require a constant expression (and hence not pit != NULL), right? :-)

[theuni]

Hmm, right. I suppose this would have to be a templated arg overloaded with nullptr_t to work, which would obviously be silly here. Nevermind!

[JeremyRubin]

The right change here might be to just only write to the pointer if it is given as argument... (e.g., a nullcheck branch not an assert)

Will, in normal execution, the assert ever panic?

[robmcl4]

From how I read it the assertion will never panic, but I agree this should be a nullcheck branch.

I see the two calls to MarkBlockAsReceived(..) which exclude the final param, on lines 2260 and 3192. Both are protected by cs_main. The former will only retrieve blocks not marked in flight and the latter uses FindNextBlocksToDownload(..), which itself only provides blocks not marked as in flight. So the assertion's branch will never be exercised in these two cases.

[practicalswift]

@JeremyRubin @robmcl4 Now changed from assert to nullcheck!

[practicalswift]

Any changes needed before merge? :-)

[paveljanik]

Why do you use different style then the style used just before return true?

[practicalswift]

@paveljanik Are you referring to the braces? if (…) … vs. if (…) { … }?

[paveljanik]

if (pit) vs if (pit != NULL)

[practicalswift]

@paveljanik Good point. Changed to if (pit) { … } for consistency and pushed. Looks good? :-)

[paveljanik]

utACK 95543d8

Sorry for the delay.

[TheBlueMatt]

utACK 95543d8

[sipa]

utACK 95543d8