FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

src: assignment to valid type by yashLadha · Pull Request #32879 · nodejs/node · GitHub

/ node Public

src: assignment to valid type - #32879

Closed
yashLadha wants to merge 1 commit into
nodejs:masterfrom
yashLadha:chore/assignment_to_valid_type
ConversationCommits (1)ChecksFiles changed
Closed

src: assignment to valid type#32879
yashLadha wants to merge 1 commit into
nodejs:masterfrom
yashLadha:chore/assignment_to_valid_type

Conversation

yashLadha commented Apr 16, 2020 •
edited
Loading

Copy link
Copy Markdown
Contributor

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 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 commented Apr 16, 2020

Copy link
Copy Markdown
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 commented Apr 16, 2020

Copy link
Copy Markdown
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 commented Apr 16, 2020

Copy link
Copy Markdown
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 commented Apr 16, 2020 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

@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 commented Apr 19, 2020

Copy link
Copy Markdown
Contributor Author

@addaleax Is something else to be done?

addaleax commented Apr 25, 2020

Copy link
Copy Markdown
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 reviewed Apr 25, 2020
View reviewed changes
Comment thread src/tcp_wrap.cc Outdated
Comment thread src/tcp_wrap.cc Outdated

yashLadha commented Apr 25, 2020

Copy link
Copy Markdown
Contributor Author

@addaleax that is a very helpful review. Checking 👍

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 force-pushed the chore/assignment_to_valid_type branch from 7a7a5f0 to 9489beb Compare April 25, 2020 11:53

nodejs-github-bot commented Apr 25, 2020

Copy link
Copy Markdown
Collaborator

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

gireeshpunathil added the author ready PRs that have at least one approval, no outstanding review comments, and a CI started. label Apr 25, 2020
gireeshpunathil pushed a commit that referenced this pull request Apr 25, 2020
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 commented Apr 25, 2020

Copy link
Copy Markdown
Member

landed in 658cae0

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
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 mentioned this pull request Apr 27, 2020
Merged
BridgeAR pushed a commit that referenced this pull request Apr 28, 2020
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
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 mentioned this pull request Apr 28, 2020
Merged
BethGriggs pushed a commit that referenced this pull request Apr 28, 2020
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
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 mentioned this pull request May 2, 2020
Merged
targos pushed a commit that referenced this pull request May 13, 2020
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>
This file contains hidden or 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
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

jasnell jasnell approved these changes
addaleax addaleax approved these changes
gireeshpunathil gireeshpunathil approved these changes

Assignees

No one assigned

Labels

author ready PRs that have at least one approval, no outstanding review comments, 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

Back | FazBrowse Home | New Git URL