Handle null pointer when attempting to build an error string

[urschrei]

It's possible that libproj will return a null pointer instead of an
actual error string. In this case we now return a specific error
indicating this.

Fixes #73

[frewsxcv]

The primary place that's affected by #73 is:

proj/src/proj.rs

Lines 133 to 139 in 81b233a

	/// Look up an error message using the error code
	fn error_message(code: c_int) -> Result<String, ProjError> {
	unsafe {
	let rv = proj_errno_string(code);
	_string(rv)
	}
	}

Specifically, the proj_errno_string function will return a null pointer if a 0 error code is passed to the function. And in such a situation, _string will attempt to dereference the null pointer which is undefined behavior, which we want to avoid.

So the question I'm wondering: do we have a guarantee that PROJ will always generate non-zero error codes?

• If the answer is 'yes, PROJ will always generate non-zero error codes', then, if we do encounter a zero error code in this function, we can assume there is some bug on our side in the proj crate codebase. And in that case, I'd propose we panic (e.g. add assert_ne!(code, 0)) so the users of our crate know it's a bug that should be reported to us, as opposed to returning an Err(...) which will subtly hide the bug.

• If the answer is 'no, PROJ will sometimes generate zero error codes', then this pull request seems good to me as we would want to surface a non-panicking error that users of this crate can gracefully handle.

[frewsxcv]

Can we add a regression test for this? Could be as simple as:

#[test]
fn error_message_zero_code() {
    assert!(error_message(0).is_err());
}

I don't want my previous message to block this as I think your pull request as-is is an improvement! Just wanted to get that thought out, as I'm not sure what the answer is. We can discuss it in a separate GitHub Issue if that's preferred

[urschrei]

OK, I'll ask the authors to clarify the error code issue, and then let's see where we are.

[frewsxcv]

Awesome, thanks for doing that. Depending on the answer, I think there are some improvements I/we/they could make to the upstream PROJ documentation to clarify as it's currently ambiguous.

[urschrei]

The smallest error code that PROJ can (should) return is 1024, so anything smaller than that should be a panic.

[urschrei]

bors try

[bors]

try

Build failed:

• ci result

[urschrei]

For some reason the proj@7 formula doesn't seem to play nicely with pkg-config, so gonna revert that change and hold off on merging this until the update to PROJ 8.1.0 has landed.

[michaelkirk]

For some reason the proj@7 formula doesn't seem to play nicely with pkg-config

Hmmm... I'm pretty sure I had the proj@7 working with the proj crate on my mac, but I'm also happy to wait until the whole pipeline is updated to proj8.

LMK if you'd like me to test anything locally on my mac.