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: stricter argument checking in toString #11120

Merged
merged 4 commits into from
Feb 5, 2017
Merged

buffer: stricter argument checking in toString #11120

merged 4 commits into from
Feb 5, 2017

Conversation

seishun
Copy link
Contributor

@seishun seishun commented Feb 2, 2017

Currently, Buffer.from('hello').toString(0, 1) returns ello, which is confusing. On the other hand, Buffer.from('hello').toString(1, 2) throws an expected error. This PR disallows passing anything other than undefined or a valid encoding as encoding.

I would love to remove the check altogether thereby also disallowing undefined, but the documentation mentions this feature and there is a test for it, so I guess it's not happening, although I can hardly imagine anyone doing this.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

buffer

This prevents the confusing behavior of `buf.toString(0, 5)` by
disallowing passing `0` as the encoding.
@nodejs-github-bot nodejs-github-bot added the buffer Issues and PRs related to the buffer subsystem. label Feb 2, 2017
@addaleax
Copy link
Member

addaleax commented Feb 2, 2017

Should we consider this semver-major?

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

Mind adding a test for it?

@cjihrig
Copy link
Contributor

cjihrig commented Feb 2, 2017

Should we consider this semver-major?

To be safe, I think so.

@addaleax addaleax added the semver-major PRs that contain breaking changes and should be released in the next major version. label Feb 2, 2017
Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

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

LGTM with a test.

@seishun
Copy link
Contributor Author

seishun commented Feb 2, 2017

Should we consider this semver-major?

Considering the docs only mention undefined, this boils down to whether anyone in the ecosystem passes any other falsy values to toString.

Mind adding a test for it?

Do you think there's an existing test file where I could add it, or does it belong in a new file?

@joyeecheung
Copy link
Member

joyeecheung commented Feb 2, 2017

@seishun Probably test-buffer-tostring-range.js?

EDIT: that's a existing one.

@seishun
Copy link
Contributor Author

seishun commented Feb 2, 2017

@joyeecheung added a test, PTAL

@thefourtheye
Copy link
Contributor

I would love to see the same change in lib/internal/util.js's normalizeEncoding as well.

@@ -82,3 +82,6 @@ assert.strictEqual(rangeBuffer.toString('ascii', 0, true), 'a');
assert.strictEqual(rangeBuffer.toString({toString: function() {
return 'ascii';
}}), 'abc');

// try toString() with 0 as the encoding
assert.throws(() => rangeBuffer.toString(0, 1, 2), /Unknown encoding/);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you improve the regular expression to something like /^TypeError: Unknown encoding: 0$/.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a similar test for null, minimally.

@@ -82,3 +82,6 @@ assert.strictEqual(rangeBuffer.toString('ascii', 0, true), 'a');
assert.strictEqual(rangeBuffer.toString({toString: function() {
return 'ascii';
}}), 'abc');

// try toString() with 0 as the encoding
assert.throws(() => rangeBuffer.toString(0, 1, 2), /Unknown encoding/);
Copy link
Member

Choose a reason for hiding this comment

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

Better include the complete message, like ^TypeError: Unknown encoding: undefined$.

@seishun
Copy link
Contributor Author

seishun commented Feb 2, 2017

@thefourtheye what public API would it affect?

@joyeecheung
Copy link
Member

@thefourtheye normalizeEncoding does coerce false and '' to utf8, not sure would anybody in the userland really pass those kinds of falsy values into the buffer methods that calls it though. Nonetheless we could at least add a test in test-internal-util-normalizeencoding.js

@thefourtheye
Copy link
Contributor

@seishun I could find only the following in a quick scan.

  • Buffer.isEncoding
  • Buffer.fill
  • Buffer.transcode
  • StringDecoder

@seishun
Copy link
Contributor Author

seishun commented Feb 2, 2017

@thefourtheye only the last two are affected, the others check the type. I don't think this is a problem, there is no confusion it can cause like in this case. In any case, it belongs in a separate PR.

@seishun seishun merged commit 9a0829d into nodejs:master Feb 5, 2017
@seishun seishun deleted the buffer-encoding-0 branch February 10, 2017 14:30
krydos pushed a commit to krydos/node that referenced this pull request Feb 25, 2017
This prevents the confusing behavior of `buf.toString(0, 5)` by
disallowing passing `0` as the encoding.

PR-URL: nodejs#11120
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@jasnell jasnell mentioned this pull request Apr 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants