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 buffer from #27051

Closed
wants to merge 3 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Apr 2, 2019

We have a lot of special casing in Buffer.from that we do not have anywhere else in the code base. There are multiple cases where it's very difficult to actually identify what the users intent was. As such, it seems best to just throw an error instead.

@nodejs/buffer this still requires the docs and error messages to be slightly updated but I'd like a first opinion.

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 added the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 2, 2019
@BridgeAR BridgeAR requested a review from bnoordhuis April 2, 2019 03:04
@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot nodejs-github-bot added the buffer Issues and PRs related to the buffer subsystem. label Apr 2, 2019
@targos

This comment has been minimized.

@BridgeAR BridgeAR added the wip Issues and PRs that are still a work in progress. label Apr 2, 2019
@BridgeAR

This comment has been minimized.

@BridgeAR BridgeAR removed the wip Issues and PRs that are still a work in progress. label Apr 16, 2019
@nodejs-github-bot
Copy link
Collaborator

@BridgeAR
Copy link
Member Author

@nodejs/buffer @nodejs/tsc this could use some reviews

@BridgeAR BridgeAR added the review wanted PRs that need reviews. label Apr 23, 2019
@BridgeAR BridgeAR requested a review from targos April 26, 2019 23:44
@BridgeAR
Copy link
Member Author

BridgeAR commented May 1, 2019

This could use some reviews.

@mcollina
Copy link
Member

mcollina commented May 1, 2019

I’m not really convinced by this change. How did we add support for toPrimitive? What was the rationale at the time?

@addaleax
Copy link
Member

addaleax commented May 1, 2019

I feel like this is a breaking change that doesn’t give us much in return, so I’d be reluctant to accept it.

I think it’s okay to remove the example from the docs as you do here – it’s not something that people would typically want to know, I assume.

@BridgeAR
Copy link
Member Author

@mcollina

How did we add support for toPrimitive? What was the rationale at the time?

@jasnell added support for it in #13725 due to #13652. There where some minor concerns mentioned about this change as well.

The reason why it was implemented seems to be that Buffer.from(Object('foobar')) did not throw but returned a buffer of the length of the boxed string. That's because a boxed string is an array like object.

@addaleax it's the only place in the whole code base where we support this. I personally think it would be best to be consistent and to prevent people from using boxed primitives in general as it's not possible to use them anywhere else either. The implementation also only supports boxed strings - no other wrapped primitive would work.

@mcollina
Copy link
Member

How did we add support for toPrimitive? What was the rationale at the time?

We'd have to dig that up, I can't recall now.

@jasnell
Copy link
Member

jasnell commented Sep 25, 2019

The toPrimitive was precisely to handle edge cases as Ruben points out. Wasn't ideal but was needed

@jasnell
Copy link
Member

jasnell commented Sep 25, 2019

Overall I'm fine with the change technically, but similar to @addaleax I'm not sure if there's enough benefit to justify the breaking change.

@BridgeAR
Copy link
Member Author

@jasnell boxed primitives do not use Symbol.toPrimitive though and will still be supported with this PR.
As far as I can tell, support for toPrimitive was added without any request for it and I think it's an edge case that we should not support (I also highly doubt that anyone uses this at all).

@jasnell
Copy link
Member

jasnell commented Sep 26, 2019

As I said, it is an edge case :-) ... if there's consensus to pull it out, I'm fine with that so long as the limitation there is documented.

@BridgeAR
Copy link
Member Author

BridgeAR commented Oct 1, 2019

This validates the byteOffset stricter to prevent ambiguous inputs
from being handled in unknown ways.
So far objects with a `length` property that was not an integer or
positive resulted in an empty buffer being created. That is not ideal
as it's not really clear what the intention in was.
This throws an error from now on instead.
The single buffer API is the only one supporting Symbol.toPrimitive
but ideally it should not be used. Remove the documentation to
prevent users from potentially using this API.
@jasnell
Copy link
Member

jasnell commented Jun 19, 2020

Ping @BridgeAR @addaleax ... is there a path forward on this one or should we close?

@jasnell jasnell added the stalled Issues and PRs that are stalled. label Jun 25, 2020
@jasnell
Copy link
Member

jasnell commented Jul 6, 2020

Closing due to lack of continued activity. @BridgeAR, please reopen if/when you plan to pick this back up again

@jasnell jasnell closed this Jul 6, 2020
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. review wanted PRs that need reviews. semver-major PRs that contain breaking changes and should be released in the next major version. stalled Issues and PRs that are stalled.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants