test: use portable EOL #32104
Closed
test: use portable EOL #32104
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The test wanted to cut huge string into 1KB strings, for which a new line character was inserted at appropriate places. The value is different in Windows (10, 13). Make it portable, by making use of os.EOL semantics Refs: nodejs#25988
gireeshpunathil
approved these changes
Mar 5, 2020
addaleax
reviewed
Mar 5, 2020
4 tasks
addaleax
approved these changes
Mar 7, 2020
addaleax
added
the
author ready
|
the modified test is failing in windows (10 and 2016) with one byte loss! can't think of a reason! |
addaleax
removed
the
author ready
Previously, the data in the file was of the structure \n
xxxxxxx...xxx\n
xxxxxxx...xxx\n
...
xxxxxxx...xxx\n
xxxxxxx...xxxwhich xxxxxxx...xxx\n
xxxxxxx...xxx\n
...
xxxxxxx...xxx\n
xxxxxxx...xxx\n(i.e. remove the empty line, but also add a trailing UNIX-style newline at the end.) I assume that now, where the file structure is \r\n
xxxxxxx...xxx\r\n
xxxxxxx...xxx\r\n
...
xxxxxxx...xxx\r\n
xxxxxxx...xxxgrep turns that into xxxxxxx...xxx\r\n
xxxxxxx...xxx\r\n
....
xxxxxxx...xxx\r\n
xxxxxxx...xxx\ni.e. grep still drops the empty line and adds a newline, but (like before) a UNIX-style one instead of a Windows-style one. |
|
great catch @addaleax !! I never knew we were loosing one byte and getting it back from |
|
@gireeshpunathil You can reproduce this pretty easily on UNIX, too, by replacing |
|
@addaleax, I made changes in the test to remove the new line in the beginning of the buffer and considered one extra byte which grep provides while doing assertion. Please take a look. |
addaleax
added
the
author ready
|
Landed in 4fedb70 |
addaleax
pushed a commit
that referenced
this pull request
Mar 13, 2020
The test wanted to cut huge string into 1KB strings, for which a new line character was inserted at appropriate places. The value is different in Windows (10, 13). Make it portable, by making use of os.EOL semantics Refs: #25988 PR-URL: #32104 Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
HarshithaKP
added a commit
to HarshithaKP/node
that referenced
this pull request
Mar 13, 2020
`buffer.write` documentation has an incaccuracy w.r.t the `length` parameter: It says default number of bytes written is `buf.length - offset`. Change it to: If the buffer has sufficient space from the offset, the string is written upto `length`. If the buffer is short in space, only `buf.length - offset` bytes are written. Refs : nodejs#32104 (comment)
BridgeAR
pushed a commit
that referenced
this pull request
Mar 17, 2020
The test wanted to cut huge string into 1KB strings, for which a new line character was inserted at appropriate places. The value is different in Windows (10, 13). Make it portable, by making use of os.EOL semantics Refs: #25988 PR-URL: #32104 Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Merged
MylesBorins
pushed a commit
that referenced
this pull request
Mar 24, 2020
The test wanted to cut huge string into 1KB strings, for which a new line character was inserted at appropriate places. The value is different in Windows (10, 13). Make it portable, by making use of os.EOL semantics Refs: #25988 PR-URL: #32104 Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
addaleax
pushed a commit
that referenced
this pull request
Apr 5, 2020
`buffer.write` documentation has an incaccuracy w.r.t the `length` parameter: It says default number of bytes written is `buf.length - offset`. Change it to: If the buffer has sufficient space from the offset, the string is written upto `length`. If the buffer is short in space, only `buf.length - offset` bytes are written. Refs: #32104 (comment) PR-URL: #32119 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
BethGriggs
pushed a commit
that referenced
this pull request
Apr 7, 2020
`buffer.write` documentation has an incaccuracy w.r.t the `length` parameter: It says default number of bytes written is `buf.length - offset`. Change it to: If the buffer has sufficient space from the offset, the string is written upto `length`. If the buffer is short in space, only `buf.length - offset` bytes are written. Refs: #32104 (comment) PR-URL: #32119 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
targos
pushed a commit
that referenced
this pull request
Apr 12, 2020
`buffer.write` documentation has an incaccuracy w.r.t the `length` parameter: It says default number of bytes written is `buf.length - offset`. Change it to: If the buffer has sufficient space from the offset, the string is written upto `length`. If the buffer is short in space, only `buf.length - offset` bytes are written. Refs: #32104 (comment) PR-URL: #32119 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
targos
pushed a commit
that referenced
this pull request
Apr 22, 2020
The test wanted to cut huge string into 1KB strings, for which a new line character was inserted at appropriate places. The value is different in Windows (10, 13). Make it portable, by making use of os.EOL semantics Refs: #25988 PR-URL: #32104 Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
targos
pushed a commit
that referenced
this pull request
Apr 22, 2020
`buffer.write` documentation has an incaccuracy w.r.t the `length` parameter: It says default number of bytes written is `buf.length - offset`. Change it to: If the buffer has sufficient space from the offset, the string is written upto `length`. If the buffer is short in space, only `buf.length - offset` bytes are written. Refs: #32104 (comment) PR-URL: #32119 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test wanted to cut huge string into 1KB strings,
for which a new line character was inserted at appropriate
places. The value is different in Windows (10, 13).
Make it portable, by making use of os.EOL semantics
Refs: #25988
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes