switch int64 to uint64 #90
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In a number of places throughout the code, we were using the `int64` type, while performing checks to ensure that the values were non-negative. The better way to do this is to switch the type to `uint64`, which will call out those errors at compile time, and will help prevent integer overflow errors, when dealing with very large numbers, as may be the case with monotonic counters. Switching these types also allows us to delete a fair amount of code for checking and testing these values. Of all the type swaps that occurred in this change, only the Counter and the MonotonicCounter wanted non-zero values. However, these values are not illegal to send to spectatord, so we are fine dropping that restriction. Also, update the monotonic counter parameter name to reflect that it is recording a value, because spectatord is now responsible for calculating the delta. Also, run `go mod tidy` to remove all of the unused dependency references.
copperlight
added a commit
that referenced
this pull request
May 11, 2024
This reverts commit 8d0203b. There are two issues with this change: (1) it is a breaking API change, and (2) it is a bit of an un-natural usage pattern, because you may need to cast variables to `uint64` in order to use these functions. In Go, there are no literals for `uint64`, so you need to declare that type up-front during the construction of a variable. If you pass an int literal to the functions, they will be accepted as long as they fit the parameters of `uint64`. We should offer support for `uint64`, particularly for `MonotonicCounter`s, which can grow large, but it should be done through additional methods such as `AddUint`, much like was done for `float64` in the `AddFloat` functions. This way, you can use `uint64`, if you need them, but common case of working with `int` literals will behave as expected.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a number of places throughout the code, we were using the
int64type, while performing checks to ensure that the values were non-negative. The better way to do this is to switch the type touint64, which will call out those errors at compile time, and will help prevent integer overflow errors, when dealing with very large numbers, as may be the case with monotonic counters. Switching these types also allows us to delete a fair amount of code for checking and testing these values.Of all the type swaps that occurred in this change, only the Counter and the MonotonicCounter wanted non-zero values. However, these values are not illegal to send to spectatord, so we are fine dropping that restriction.
Also, update the monotonic counter parameter name to reflect that it is recording a value, because spectatord is now responsible for calculating the delta.
Also, run
go mod tidyto remove all of the unused dependency references.