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.

Sign up for GitHub

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

Jump to bottom

src: assignment to valid type #32879

Closed
wants to merge 1 commit into from
Closed

src: assignment to valid type #32879

wants to merge 1 commit into from

Conversation

yashLadha
Copy link
Contributor

@yashLadha yashLadha commented Apr 16, 2020 •
edited
Loading

We are doing conversion of arguments to uint32_t but the lvalue type
is not consistent with the casting. Also, the lvalue type differs at
different occurrences. Ideally, such changes should be picked up by the linter, can we move forward in this direction 🤔 .

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. net Issues and PRs related to the net subsystem. labels Apr 16, 2020
@addaleax
Copy link
Member

@yashLadha This PR moves the type conversions from the place where we extract the native value from the passed JS value to the place where we pass the native value to libuv, but the conversions are still there and they are still the same.

I guess for TCPWrap::Connect it makes sense to use Int32 instead of Uint32, though.

@yashLadha
Copy link
Contributor Author

@addaleax My argument for this change is to have a consistent type for the assignment because we are casting the values as Uint32 and storing it an int or unsigned int, isn't the value in which we are storing should follow the same type for consistency.

I guess for TCPWrap::Connect it makes sense to use Int32 instead of Uint32, though.

For this what should be cases when it can be negative, as port is always a positive property

@addaleax
Copy link
Member

@yashLadha I’m not arguing against this, to be clear :) I’m just pointing out that this performs the same type conversions and has the same behavior as it did before.

@yashLadha
Copy link
Contributor Author

yashLadha commented Apr 16, 2020 •
edited
Loading

@addaleax Got it, but when browsing through the code, the cast and the type of lvalue seemed inconsistent that's why i created this PR. 😄 I know it won't make any difference because both can store the value but enforcing it I thought would be a good idea.

@yashLadha
Copy link
Contributor Author

@addaleax Is something else to be done?

@addaleax
Copy link
Member

@yashLadha I think somebody needs to approve this PR.

If you want my personal opinion, I think I’d be -0.005 on this, given that it makes the cast a bit less visible (you’d have to look up the definitions of the libuv functions to know that it is happening, instead of just “seeing” it like you did), and I would be +0.005 on a PR that adds static_cast to be explicit about the conversions, but ultimately, I don’t have a strong opinion on anything here.

gireeshpunathil
gireeshpunathil reviewed Apr 25, 2020
View reviewed changes
src/tcp_wrap.cc Outdated Show resolved Hide resolved
src/tcp_wrap.cc Outdated Show resolved Hide resolved
@yashLadha
Copy link
Contributor Author

@addaleax that is a very helpful review. Checking 👍

@yashLadha
src: assignment to valid type
9489beb 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.
@yashLadha yashLadha force-pushed the chore/assignment_to_valid_type branch from 7a7a5f0 to 9489beb Compare April 25, 2020 11:53
@nodejs-github-bot
Copy link
Collaborator

CI: https://ci.nodejs.org/job/node-test-pull-request/30974/

@gireeshpunathil gireeshpunathil added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 25, 2020
gireeshpunathil pushed a commit that referenced this pull request Apr 25, 2020
@yashLadha @gireeshpunathil
src: assignment to valid type
658cae0 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@gireeshpunathil
Copy link
Member

landed in 658cae0

@yashLadha yashLadha deleted the chore/assignment_to_valid_type branch April 25, 2020 15:24
BethGriggs pushed a commit that referenced this pull request Apr 27, 2020
@yashLadha @BethGriggs
src: assignment to valid type
be4703e 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@BethGriggs BethGriggs mentioned this pull request Apr 27, 2020
Merged
BridgeAR pushed a commit that referenced this pull request Apr 28, 2020
@yashLadha @BridgeAR
src: assignment to valid type
2264b56 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
BridgeAR pushed a commit that referenced this pull request Apr 28, 2020
@yashLadha @BridgeAR
src: assignment to valid type
f155690 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@BridgeAR BridgeAR mentioned this pull request Apr 28, 2020
Merged
BethGriggs pushed a commit that referenced this pull request Apr 28, 2020
@yashLadha @BethGriggs
src: assignment to valid type
44c157e 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
targos pushed a commit that referenced this pull request Apr 30, 2020
@yashLadha @targos
src: assignment to valid type
6872d07 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
@targos targos mentioned this pull request May 2, 2020
Merged
targos pushed a commit that referenced this pull request May 13, 2020
@yashLadha @targos
src: assignment to valid type
b893c5b 
We are converting the argument to a uint32_t value
but the lvalue is not consistent with the casting.

PR-URL: #32879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gireeshpunathil gireeshpunathil gireeshpunathil approved these changes

@addaleax addaleax addaleax approved these changes

@jasnell jasnell jasnell approved these changes

Assignees
No one assigned
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. c++ Issues and PRs that require attention from people who are familiar with C++. net Issues and PRs related to the net subsystem.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@yashLadha @addaleax @nodejs-github-bot @gireeshpunathil @jasnell