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

fs: change default value of position in read and readSync #37101

Conversation

RaisinTen
Copy link
Contributor

Since the docs mention that position in read and readSync should
be an integer or a bigint, the functions should rather accept what
is actually fed into read, i.e., -1 instead of any nullish value.

@nodejs-github-bot nodejs-github-bot added the fs Issues and PRs related to the fs subsystem / file system. label Jan 27, 2021
@RaisinTen
Copy link
Contributor Author

Not necessarily something to be done in this PR and I haven't looked super-closely but I wonder if this bit of code means that the docs shouldn't say the default is null but instead should say the default is -1 (and be sure to explain what -1 means and make sure that passing -1 explicitly works). Saying the thing has to be a an integer (or bigint, as added in this PR), but then saying the default is something that is not an integer or bigint (null), seems confusing and not quite right.

Originally posted by @Trott in #36190 (comment)

cc @Trott Since you mentioned this idea.

@@ -79,7 +79,7 @@ function tempFdSync(callback) {
const buf = Buffer.alloc(5);

// Read only five bytes, so that the position moves to five.
fs.read(fd, buf, 0, 5, null, common.mustSucceed((bytes) => {
fs.read(fd, buf, 0, 5, -1, common.mustSucceed((bytes) => {
Copy link
Contributor

@aduh95 aduh95 Jan 27, 2021

Choose a reason for hiding this comment

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

Can you keep the null test please? We want null to still works – or mark the PR as semver-major.

EDIT: I've added the semver-major label, you can remove it if you change the code to rollback the behaviour for null.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this should be semver-major as it is supposed to reject a null value for position which was accepted previously. Thanks for adding the label.

Copy link
Contributor

Choose a reason for hiding this comment

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

On a second thought, we should probably deprecate it before removing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added the deprecation warning, test and mentioned the PR link in the YAML. PTAL. 👀

@aduh95 aduh95 added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jan 27, 2021
aduh95
aduh95 previously approved these changes Jan 27, 2021
@@ -546,9 +546,6 @@ function read(fd, buffer, offset, length, position, callback) {

validateOffsetLengthRead(offset, length, buffer.byteLength);

if (position == null)
position = -1;

Copy link
Member

Choose a reason for hiding this comment

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

We should actually keep this with if (position === null) given that the default assignment will not work when position is explicitly passed as null.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jasnell Note this was intentional, see #37101 (comment) above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jasnell added the check back in along with a deprecation warning.

@@ -612,9 +613,6 @@ function readSync(fd, buffer, offset, length, position) {

validateOffsetLengthRead(offset, length, buffer.byteLength);

if (position == null)
position = -1;
Copy link
Member

Choose a reason for hiding this comment

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

Likewise here, this check should be kept

@RaisinTen RaisinTen force-pushed the fs/change-default-value-of-position-in-read branch from 70f5ff4 to 5145747 Compare January 28, 2021 15:41
@aduh95 aduh95 added deprecations Issues and PRs related to deprecations. notable-change PRs with changes that should be highlighted in changelogs. labels Jan 29, 2021
@aduh95
Copy link
Contributor

aduh95 commented Jan 29, 2021

Usually we tend to avoid going Runtime deprecation without a doc-only deprecation first – unless there's a security risk we are trying to mitigate, but that's not the case here. You also need to add the deprecation description on deprecation.md.

Refs: https://github.com/nodejs/node/blob/master/doc/guides/collaborator-guide.md#deprecations

@RaisinTen
Copy link
Contributor Author

Okay. Should I open a separate PR to make it a doc-only deprecation first? After that lands, we can work on this PR to add the runtime warning. Finally, a PR can be raised to turn it into an EOL deprecation.

@wa-Nadoo
Copy link

The proposed default value for position seems confusing to me. Negative values feel like regular position values but in reverse order. Undefined/null seems more obvious.

@RaisinTen
Copy link
Contributor Author

@wa-Nadoo -1 is actually the standard value for offset (or position from the side of Node.js) you pass to preadv2(https://man7.org/linux/man-pages/man2/preadv2.2.html) if you want the current file offset to be used and updated.

@Trott
Copy link
Member

Trott commented Jan 31, 2021

What's the reason for deprecating null? If it's an abstract sense of correctness, I would prefer to keep it around rather than break people's code for abstract ideals. On the other hand, if there is a true maintenance burden with keeping it, then sure, let's deprecate and remove.

@RaisinTen
Copy link
Contributor Author

I intended to deprecate null because it previously allowed fs.read and fs.readSync to accept two different values for the same operation synthetically, by substituting null with -1 inside the functions since the underlying API uses -1. If the check is removed, the code will also become more efficient, which might be noticeable if there are lots of calls to these functions.

@PoojaDurgad
Copy link
Contributor

need rebase to resolve git-conflicts

Since the docs mention that `position` in `read` and `readSync` should
be an `integer` or a `bigint`, the functions should rather accept what
is actually fed into `read`, i.e., `-1` instead of any nullish value.
@RaisinTen RaisinTen force-pushed the fs/change-default-value-of-position-in-read branch from 6a815f7 to 446bdb6 Compare March 31, 2021 14:24
@RaisinTen
Copy link
Contributor Author

@PoojaDurgad Thanks for mentioning, I rebased it.

@RaisinTen
Copy link
Contributor Author

Usually we tend to avoid going Runtime deprecation without a doc-only deprecation first – unless there's a security risk we are trying to mitigate, but that's not the case here. You also need to add the deprecation description on deprecation.md.

Refs: https://github.com/nodejs/node/blob/master/doc/guides/collaborator-guide.md#deprecations

@aduh95 Finally opened the PR to doc-only deprecate this - #38043. :)

@aduh95 aduh95 dismissed their stale review April 2, 2021 16:34

Note that I appreciate the time you spend working in this, but I think Rich has a point. Also if #37948 lands, I'd be -1 to land this.

@RaisinTen
Copy link
Contributor Author

@aduh95 Thank you for the review.

Along with deprecating nullish values for position, I was also considering deprecating nullish values for offset. Though not documented, since offset is validated the same way as position, fs.read and fs.readSync actually allow the value null for offset too, which is not a valid integer.

Should documenting this be okay if #37948 lands?

Even if we document this, wouldn't it feel weird why the default value for offset is not null while that of position is? I'm assuming changing the default value is semver-major.

@aduh95
Copy link
Contributor

aduh95 commented Apr 5, 2021

Changing a default is not necessarily semver-major, as long as it is not a breaking change.

Should documenting this be okay if #37948 lands?

IMHO changing the value in the docs makes sense, whether or not #37948 lands.

I don't have a strong opinion regarding deprecation status of nullish values, I tend to be on board for calling it legacy and keep it as is though.

@RaisinTen
Copy link
Contributor Author

@aduh95 I noticed the validation logic is similar in fs Promises API. Would it make sense to make these validation changes to the FileHandle variations of these functions instead? The APIs will become a bit inconsistent with each other then.

@aduh95
Copy link
Contributor

aduh95 commented Apr 8, 2021

I don't really have an opinion, I guess it would make sense to change all default values documented to -1 instead of null, but I don't feel strongly about it.

@RaisinTen
Copy link
Contributor Author

I don't think this is worth the breakage anymore.

@RaisinTen RaisinTen closed this Mar 18, 2022
@RaisinTen RaisinTen deleted the fs/change-default-value-of-position-in-read branch March 18, 2022 06:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecations Issues and PRs related to deprecations. fs Issues and PRs related to the fs subsystem / file system. notable-change PRs with changes that should be highlighted in changelogs. 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.

None yet

7 participants