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

r.stats: Use long total_count to avoid int overflow #3203

Merged
merged 2 commits into from
Dec 7, 2023

Conversation

HuidaeCho
Copy link
Member

@HuidaeCho HuidaeCho commented Oct 13, 2023

This PR fixes an integer overflow (sum % with -p higher than 100%) by using long total_count.

@HuidaeCho HuidaeCho added raster Related to raster data processing enhancement New feature or request labels Oct 13, 2023
@HuidaeCho HuidaeCho changed the title Use long total_count to avoid int overflow r.stats: Use long total_count to avoid int overflow Oct 13, 2023
@wenzeslaus
Copy link
Member

Pylint is broken due to an update of Pylint plugin for pytest. While the Pylint is set to 2.12.2. The pytest plugin updated from 0.19.0 to 0.21.0. That's something which needs to be fixed separately by setting the plugin version to 0.19.0 (fast) or updating to 0.21.0 and fixing the reported issues (slow).

Additional checks is broken on main as well due to #3170.

@HuidaeCho
Copy link
Member Author

Pylint is broken due to an update of Pylint plugin for pytest. While the Pylint is set to 2.12.2. The pytest plugin updated from 0.19.0 to 0.21.0. That's something which needs to be fixed separately by setting the plugin version to 0.19.0 (fast) or updating to 0.21.0 and fixing the reported issues (slow).

What about the pytest version?

Additional checks is broken on main as well due to #3170.

@wenzeslaus
Copy link
Member

What about the pytest version?

I don't recall. It should be in some of the old runs. Either it was the same (it did not update) or I just thought the plugin is to blame given that it is related to what the plugin does. However, specifying the version of pytest will be needed eventually anyway.

@@ -27,7 +27,8 @@ struct Node {

static struct Node **hashtable;
static struct Node *node_list = NULL;
static int node_count = 0, total_count = 0;
static int node_count = 0;
static long total_count = 0;
Copy link
Member

Choose a reason for hiding this comment

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

Sometimes (Windows?), int might be just as large as long. While the minimums are 16 and 32, sizes can be 32 and 32 or 32 and 64 according to https://en.cppreference.com/w/cpp/language/types (C++, C does not have that nice description but since it depends on the compiler anyway, I guess it applies the same way).

I think someone brought this up in the past, but I don't recall if we have a best practice for that.

Copy link
Contributor

@nilason nilason Nov 20, 2023

Choose a reason for hiding this comment

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

If total_count is guaranteed to be >=0 unsigned int could be a better alternative, otherwise grass_int64 may be considered.

Copy link
Member Author

Choose a reason for hiding this comment

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

I chose long because Node.count is long.

Copy link
Member

Choose a reason for hiding this comment

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

In r.in.pdal, I used typedef which goes for unsigned long or unsigned long long for number of points depending on HAVE_LONG_LONG_INT. However, I think grass_int64 is better as it is aligned with the new(ish) trend of fixed with integers (C99, C++11). Signed versus unsigned and int64_t versus grass_int64, that's whole another discussion.

However, if int->long helps in your case and it fits with the other numbers there, I'm not against merging this as is.

Copy link
Contributor

@nilason nilason left a comment

Choose a reason for hiding this comment

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

However, if int->long helps in your case and it fits with the other numbers there, I'm not against merging this as is.

I agree, if this solves your issue, please go ahead and merge.

@HuidaeCho HuidaeCho merged commit 75328b4 into OSGeo:main Dec 7, 2023
18 checks passed
@HuidaeCho HuidaeCho deleted the r_stats_long_count branch December 7, 2023 15:47
HuidaeCho added a commit to HuidaeCho/grass that referenced this pull request Jan 9, 2024
Co-authored-by: Markus Neteler <neteler@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request raster Related to raster data processing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants