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

buffer: use a default offset #19749

Closed
wants to merge 3 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Apr 2, 2018

If none is provided, use zero as a default offset for all read/write operations on the buffer.

This reverts some former changes to make sure the default offset for buffer read / write functions is set to zero. This was possible before due to the implicit type coercion.

I only added support for the functions that do not require a byteLength because writing e.g., buffer.readIntBe(undefined, 4) is very likely a bug in the users code and not expected to be zero.

At the same time I added a documentation-only deprecation for the default offset. There were six modules with > 10dm that used this notation and three of those merged my fix already.

Refs: #18395

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

@BridgeAR BridgeAR requested review from ChALkeR and addaleax April 2, 2018 12:34
@nodejs-github-bot nodejs-github-bot added the buffer Issues and PRs related to the buffer subsystem. label Apr 2, 2018
@BridgeAR BridgeAR added dont-land-on-v6.x and removed buffer Issues and PRs related to the buffer subsystem. labels Apr 2, 2018

Using a read or write functions without offset is very seldom useful besides by
using it in the repl / for testing purposes. To make sure the intent is properly
understood, please always add a offset instead of omitting it.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: a offset -> an offset.

@jasnell jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 2, 2018
@jasnell
Copy link
Member

jasnell commented Apr 2, 2018

semver-major by default unless TSC decides to go semver-minor with it.

@addaleax
Copy link
Member

addaleax commented Apr 2, 2018

@jasnell Fyi, this is specifically fixing up an unintended breaking change from a previous semver-major commit. It brings behaviour back that exists in all release lines.

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

lib/ and test/ LGTM, thanks!

@@ -979,6 +979,15 @@ Type: Runtime
This was an undocumented helper function not intended for use outside Node.js
core and obsoleted by the removal of NPN (Next Protocol Negotiation) support.

<a id="DEP00XX"></a>
### DEP00XX: Buffer#(read|write) functions without offset
Copy link
Member

Choose a reason for hiding this comment

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

If you want to deprecate this, that should also be noted in the buffer.md docs.

However, I would suggest not deprecating this, or at least splitting that out into a different PR?

Copy link
Member

Choose a reason for hiding this comment

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

Splitting out to a separate PR would likely be best. It would, for instance, stop this from being a semver-major :-)

Copy link
Member

Choose a reason for hiding this comment

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

Yes, +1 to splitting the doc-deprecation to a separate PR so we could review the fix separately and without debating on the doc-deprecation.

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 removed the deprecation as suggested.

@BridgeAR
Copy link
Member Author

BridgeAR commented Apr 2, 2018

@ChALkeR ChALkeR added this to the 10.0.0 milestone Apr 4, 2018
@ChALkeR ChALkeR removed the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 4, 2018
@ChALkeR
Copy link
Member

ChALkeR commented Apr 4, 2018

@addaleax @jasnell Doesn't seem to be a semver-major anymore after the deprecation is removed from this PR. It still shouldn't be backported to 9.x and below though as it is a fix-up for an already landed semver-major patch.

@@ -57,6 +57,8 @@ function boundsError(value, length, type) {

// Read integers.
function readUIntLE(offset, byteLength) {
if (offset === undefined)
Copy link
Member

@ChALkeR ChALkeR Apr 4, 2018

Choose a reason for hiding this comment

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

buffer.readUIntLE() works on Node.js 9.x. Default offset is 0, default byteLength is 1.
Should this function be patched or is that set somewhere else?

Copy link
Member Author

@BridgeAR BridgeAR Apr 4, 2018

Choose a reason for hiding this comment

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

Ah, good to know. I did not check that before. Even though this case is even a weirder use case... are we certain we want to support that? Right now there is not a single module that does this that has more than 10k downloads / month. That applies to all Buffer#(read|write)U?Int(L|B)E functions.

Copy link
Member

Choose a reason for hiding this comment

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

It’s an odd case, and it’s not ideal because it definitely doesn’t convey author intent very well, but if we do want to remove support for it, that should be a conscious decision (i.e. the default should be to keep it for now, imo)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, so I'll add support for it first and then open a PR to suggest removing support for it? :D

Copy link
Member

Choose a reason for hiding this comment

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

@BridgeAR I think for behaviour that goes back this long (at least v0.12) and gave well-defined results, we should deprecate it if we do want to change runtime behaviour

But generally: Why? What’s the benefit of that? Yes, it’s good to convey author intent as well as possible when writing code, but taking care of that is just not our job… if we want people to have a canonical way to do something, that’s what documentation and docs-only deprecations are for.

Copy link
Member Author

Choose a reason for hiding this comment

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

@addaleax I just checked all npm js modules for this pattern and there is not a single hit for either no arguments or the first argument being undefined. It is very unlikely that anyone would want to call this function like this instead of calling Buffer#(read|write)U?Int8. I guess if this is ever called that way, it is actually a user bug and it is best to return an error instead. So I would like to keep it the way it is.

Copy link
Member

Choose a reason for hiding this comment

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

@BridgeAR Yeah, you’re right, this would most likely point to a user bug, and it seems fair to remove support as a semver-major change. (But stil, that should be a conscious decision that we’re making.)

@ChALkeR
Copy link
Member

ChALkeR commented Apr 4, 2018

@BridgeAR Could you add a test to verify that buffer.readUIntLE() and buffer.readUIntLE(offset) are working as expected?

@BridgeAR
Copy link
Member Author

BridgeAR commented Apr 4, 2018

@ChALkeR so if I understand you correct you do not agree with #19749 (comment)?

@ChALkeR
Copy link
Member

ChALkeR commented Apr 4, 2018

@BridgeAR Removal or deprecation of that should be done in a separate PR with a separate discussion.
I would prefer this PR to just restore the offset behavior that we had in 9.x as deprecation/breakage of that behaviour was not properly discussed.

@BridgeAR
Copy link
Member Author

BridgeAR commented Apr 5, 2018

@ChALkeR are you feeling strongly about first adding the support back in? In the end: it is nothing I am impacted and I do not want to invest to much energy into this but I believe we improve our user experience by keeping this PR as it is. I can only imagine this being a bug if a user will ever encounter this. When checking gzemnid I could also not find a single use case in any module (not only the top code but all modules).

@BridgeAR
Copy link
Member Author

BridgeAR commented Apr 9, 2018

Ping @ChALkeR

@BridgeAR
Copy link
Member Author

@ChALkeR I pushed another fixup to fully reinstate the default values as it was possible before (I still think any such use case is actually a bug). I hope the PR can now land out of your perspective.

@BridgeAR
Copy link
Member Author

If none is provided, use zero as a default offset for all read/write
operations on the buffer.
@BridgeAR BridgeAR force-pushed the accept-omitted-offset branch from 81b0d21 to 12e344a Compare April 10, 2018 02:04
@BridgeAR
Copy link
Member Author

Rebased due to conflicts about the former deprecations part.

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

@ChALkeR ChALkeR self-requested a review April 10, 2018 02:38
@BridgeAR
Copy link
Member Author

New CI (I had a regression): https://ci.nodejs.org/job/node-test-pull-request/14180/

@BridgeAR
Copy link
Member Author

10.x is coming nearer each day, so I plan on landing this in ~30 hours if there is no objection until then.

@jasnell
Copy link
Member

jasnell commented Apr 12, 2018

Even tho this is not semver-major, I'd feel better with a CITGM run on this.

@BridgeAR
Copy link
Member Author

@jasnell this restores original behavior of 9.x, so there is no need to run the CITGM here.

@jasnell
Copy link
Member

jasnell commented Apr 13, 2018

still LGTM.

BridgeAR added a commit to BridgeAR/node that referenced this pull request Apr 13, 2018
If none is provided, use zero as a default offset for all read/write
operations on the buffer.

PR-URL: nodejs#19749
Refs: nodejs#18395
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@BridgeAR
Copy link
Member Author

Landed in d5495e8

@BridgeAR BridgeAR closed this Apr 13, 2018
@ChALkeR ChALkeR removed their request for review April 13, 2018 18:12
jasnell pushed a commit that referenced this pull request Apr 16, 2018
If none is provided, use zero as a default offset for all read/write
operations on the buffer.

PR-URL: #19749
Refs: #18395
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@BridgeAR BridgeAR deleted the accept-omitted-offset branch April 1, 2019 23:40
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