Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add error return codes to gridDisk functions #505

Merged
merged 10 commits into from
Oct 18, 2021

Conversation

isaacbrodsky
Copy link
Collaborator

Adds the ability for the gridDisk series of functions (but not maxGridDiskSize, which may need to be updated to return int64_t) to return errors.

@isaacbrodsky
Copy link
Collaborator Author

There may be some unreachable branches in this PR, I will see if I can get coverage on them or otherwise deduplicate some of the error handling.

@coveralls
Copy link

coveralls commented Aug 13, 2021

Coverage Status

Coverage decreased (-0.2%) to 98.513% when pulling ccd7066 on isaacbrodsky:error-returns-griddisk into 0302b93 on uber:master.

src/h3lib/lib/algos.c Outdated Show resolved Hide resolved
Comment on lines 1095 to 1097
// TODO: The return value, possibly indicating an error, is discarded here -
// we should use this when we update the API to return a value
normalizeMultiPolygon(out);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this function also be updated so it can return the error here?

@isaacbrodsky
Copy link
Collaborator Author

We also need to update the docs for gridDisk.

@isaacbrodsky
Copy link
Collaborator Author

This should be ready for review. I began updating some additional functions in traversal.mdx while doing this.

src/h3lib/lib/algos.c Outdated Show resolved Hide resolved
// Optimistically try the faster gridDiskUnsafe algorithm first
const bool failed =
const H3Error failed =
H3_EXPORT(gridDiskDistancesUnsafe)(origin, k, out, distances);
if (failed) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is E_SUCCESS supposed to be opaque? If so, maybe if (result != E_SUCCESS) would be better than assuming 0.

Either way, we should be consistent with our internal handling here - either always use falsy checks or always use inequality checks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are tied to E_SUCCESS == 0 and non-zero being an error, so my suggestion would be to test for any non-zero value.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure that sounds good. In that case, there are a lot of if (result != E_SUCCESS) checks we should probably update. I'd also consider getting consistent around naming - maybe error rather than failed, e.g.

H3Index h3NeighborRotations(H3Index origin, Direction dir, int *rotations) {
H3Index out = origin;
H3Error h3NeighborRotations(H3Index origin, Direction dir, int *rotations,
H3Index *out) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'd consider swapping the order of int *rotations, H3Index *out in the arg list. rotations is also an "out" argument, but it's less important than out, and in other languages you'd make it optional, which suggests that it should go last in the arg list. Not a big deal though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rotations is both an in and out parameter, which makes it a little trickier. Does that make this ordering make more sense or does it still seem of lesser importance?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I missed that we were using rotations for more than reporting to the caller. Many of the callsites pre-set this to 0, but I guess gridDiskUnsafe and gridRingUnsafe use this as a real input param. Probably stet in this case.

src/h3lib/lib/algos.c Outdated Show resolved Hide resolved
*rotations = *rotations + 5;
} else {
// Should never occur
return H3_NULL; // LCOV_EXCL_LINE
return E_FAILED; // LCOV_EXCL_LINE
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that the coverage drops are because this is the only failure case for this function, and we've added a few if (neighborResult != E_SUCCESS) branches after calls to this function.

It looks like we might be able to force failure here with an invalid index, with an INVALID_DIGIT setting as the leading non-zero digit?

origin, NEXT_RING_DIRECTION, &rotations, &origin);
if (neighborResult) {
return neighborResult;
}
if (origin == 0) { // LCOV_EXCL_BR_LINE
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: H3_NULL? Also, would h3NeighborRotations ever set out to H3_NULL now, or is this check meaningless?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are correct that we should update h3NeighborRotations docs and callsites to not look for H3_NULL.

@@ -395,27 +406,28 @@ H3Index h3NeighborRotations(H3Index origin, Direction dir, int *rotations) {
// base cell.
if (oldLeadingDigit == CENTER_DIGIT) {
// Undefined: the k direction is deleted from here
return H3_NULL;
return E_SUCCESS;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look right - out is not set in this case

@isaacbrodsky isaacbrodsky merged commit 583de2f into uber:master Oct 18, 2021
@isaacbrodsky isaacbrodsky deleted the error-returns-griddisk branch October 18, 2021 21:54
isaacbrodsky added a commit to isaacbrodsky/oss-fuzz that referenced this pull request Oct 20, 2021
uber/h3#505 updated this function to have a different signature; I assume this wasn't caught as a build error because the fuzzer is calling an internal function of the library that isn't in the `h3api.h` header.
DavidKorczynski pushed a commit to google/oss-fuzz that referenced this pull request Oct 20, 2021
uber/h3#505 updated this function to have a different signature; I assume this wasn't caught as a build error because the fuzzer is calling an internal function of the library that isn't in the `h3api.h` header.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants