Prevent null pointer dereference in bwriteprotect macro usage

[rdmark]

Aborts instead of asserts before using the bwriteprotect macro with a null parameter, to avoid null pointer dereference

[rdmark]

@msteinert Sonar reports now one outstanding bug, in the bwriteprotect macro, which seems legit to my eyes. This PR should protect against this scenario, but Sonar is now reporting 10 new bugs that are clearly spurious, unless I'm overlooking something obvious. Would you mind taking a look at the latest report and tell me what you think?

[msteinert]

It seems like the analyzer forgot how return works in this case?

I'm usually reluctant to say the analyzer is wrong, but it does seem that way in this case.

[msteinert]

I wonder if the static analyzer would be less confused if the conditions were combined?

if (b0 == NULL || res == NULL) {
        ck_abort();
        return; /* Just a safeguard */
}

...

Granted, this is less useful for debugging a failure.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rdmark]

This approach actually appeased the static analyzer for three of the cases. I've pushed a commit now that slightly refactors the rest with else statements that cleanly splits out the branches.

Still not sure why Sonar picks up on these particular branches.