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

stream: check type and range of highWaterMark #18098

Closed
wants to merge 7 commits into from

Conversation

tniessen
Copy link
Member

Continuation of #13065.

Stream constructors should throw when an invalid highWaterMark option is given.

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
Affected core subsystem(s)

stream

The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. stream Issues and PRs related to the stream subsystem. labels Jan 11, 2018
@tniessen
Copy link
Member Author

There are two aspects which I would like to discuss:

  1. NaN is accepted but ignored. This is the expected behavior according to test-stream-transform-split-highwatermark, but I don't see much value in that.
  2. Floating point numbers are permitted and rounded to integers.

@mcollina
Copy link
Member

I'm 👍 in removing support for NaN, i.e. throwing if it is passed.
I would keep the rounding, as it might happen that highWaterMark  is the result of some division, and I don't think the rounding harms

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

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

I suggest to implement this in a more efficient way.

I also agree with @mcollina that NaN should not be supported anymore.

LGTM otherwise!


// Default value
return state.objectMode ? 16 : 16 * 1024;
}
Copy link
Member

@BridgeAR BridgeAR Jan 11, 2018

Choose a reason for hiding this comment

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

The following should be more efficient (untested):

function getHighWaterMark (options, isDuplex, specialKey, objectMode) {
  if (typeof options.highWaterMark === 'number') {
    if (options.highWaterMark < 0 || Number.isNaN(options.highWaterMark)) {
      throw new errors.TypeError(
        'ERR_INVALID_OPT_VALUE',
        'options.highWaterMark',
        options.highWaterMark
      )
    }
    return Math.floor(options.highWaterMark)
  }
  if (isDuplex) {
    if (typeof options[specialKey] === 'number') {
      if (options[specialKey] < 0 || Number.isNaN(options[specialKey])) {
        throw new TypeError(...)
      }
      return Math.floor(options[specialKey])
    }
    if (options[specialKey]) {
      throw new TypeError(...)
    }
  } else if(options.highWaterMark) {
    throw new TypeError(...)
  }

  return objectMode ? 16 : 16 * 1024
}

getHighWaterMark(
  options,
  isDuplex,
  'writableHighWaterMark', // Replace accordingly
  this.objectMode
)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I was going to extract the key anyway, just wanted to hear opinions about NaN first (that really annoyed me).

Copy link
Member Author

Choose a reason for hiding this comment

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

By the way, !(options.highWaterMark >= 0) should be faster than options.highWaterMark < 0 || Number.isNaN(options.highWaterMark).

Copy link
Member

Choose a reason for hiding this comment

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

That is probably true.

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

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@tniessen tniessen added this to the 10.0.0 milestone Jan 11, 2018
@BridgeAR BridgeAR requested a review from a team January 14, 2018 13:53
@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 14, 2018
@mcollina
Copy link
Member

This needs a CITGM before landing run after #18210 lands and we get CITGM back.

@addaleax addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 18, 2018
@tniessen
Copy link
Member Author

@tniessen
Copy link
Member Author

citgm looks good to me, can someone confirm?

@addaleax
Copy link
Member

@tniessen yup, looks good to me too 👍

@tniessen
Copy link
Member Author

tniessen commented Jan 22, 2018

@tniessen tniessen added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 23, 2018
tniessen added a commit that referenced this pull request Jan 29, 2018
The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.

PR-URL: #18098
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@tniessen
Copy link
Member Author

Landed in 46e0a55.

@tniessen tniessen closed this Jan 29, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.

PR-URL: nodejs#18098
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@tniessen tniessen removed author ready PRs that have at least one approval, no pending requests for changes, and a CI started. labels Sep 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. semver-major PRs that contain breaking changes and should be released in the next major version. stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants