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

Overflow/underflow check for -maxsendbuffer and -maxreceivebuffer #588

Merged
merged 1 commit into from
Sep 29, 2023

Conversation

JackPiri
Copy link
Contributor

@JackPiri JackPiri commented Aug 3, 2023

Handling cases like -maxsendbuffer=-1, -maxsendbuffer=0, -maxsendbuffer=4294967296, etc...

Copy link
Contributor

@a-petrini a-petrini left a comment

Choose a reason for hiding this comment

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

Looks good, thanks!

Copy link
Contributor

@ptagl ptagl left a comment

Choose a reason for hiding this comment

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

Thanks for the effort in improving checks on input parameters!

To me, the changes seem in line with the typical approach used in that file, I was wondering if we could start thinking of a new approach to separate parameters validation from usage.

In particular, I wonder if we could introduce a new function like ValidateStartupArguments() that takes care of performing all the sanity checks on the inputs while keeping AppInit2() lite and more readable.

Given that we may be using similar validations for several arguments in the future, we may also think of including a second util function like ValidateRanges(argKey, [optional] min, [option] max) to reduce code duplication.

In such a way, we could probably also easily increase code coverage with some unit tests.

What do you think?

Copy link
Contributor

@drgora drgora left a comment

Choose a reason for hiding this comment

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

Thank you for the PR! I left a small comment that I believe should be addressed before merging.
I also second @ptagl on his comment on modularization.

@JackPiri JackPiri force-pushed the gp/check_max(receive-send)buffer branch from 0aaae21 to f57c439 Compare August 7, 2023 08:10
Copy link
Contributor

@titusen titusen left a comment

Choose a reason for hiding this comment

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

I agree with Paolos comments. The rest LGTM, thanks.

@JackPiri JackPiri force-pushed the gp/check_max(receive-send)buffer branch from f57c439 to 920c69d Compare September 27, 2023 14:06
Copy link
Contributor

@drgora drgora left a comment

Choose a reason for hiding this comment

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

This PR looks good to me. I left a couple small comments that I believe might be good addressing before merge, but not blocking. Thank you.

@JackPiri JackPiri force-pushed the gp/check_max(receive-send)buffer branch 3 times, most recently from e2db4ce to 8e8391b Compare September 29, 2023 10:29
@JackPiri JackPiri force-pushed the gp/check_max(receive-send)buffer branch from 8e8391b to 02d3c0f Compare September 29, 2023 11:04
@ptagl ptagl merged commit 4cd1eac into main Sep 29, 2023
@ptagl ptagl deleted the gp/check_max(receive-send)buffer branch September 29, 2023 13:34
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.

6 participants