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

(still broken) str: stop encoding invalid code points #5151

Closed
wants to merge 1 commit into from
Closed

(still broken) str: stop encoding invalid code points #5151

wants to merge 1 commit into from

Conversation

thestinger
Copy link
Contributor

Currently fails in the json::tests::test_read_str test. I'm not sure why.

The highest valid code point is 1114111 (0x10FFFF) and the modern UTF-8
standard guarantees that the maximum number of bytes needed to encode a
code point is 4 (instead of 6, in the legacy standard).

From https://tools.ietf.org/html/rfc3629:

Changes from RFC 2279

o Restricted the range of characters to 0000-10FFFF (the UTF-16
accessible range).

@graydon
Copy link
Contributor

graydon commented Mar 5, 2013

Failure might have to do with the escape value \x08 in one of the tests? Possibly some relationship to #2800 ?

@lucab
Copy link
Contributor

lucab commented Apr 5, 2013

Reducing the test-case, I can see this PR failing the assertion on the first case, ie. on a simple std::json::from_str(~""").
Not sure why, though.

@brson
Copy link
Contributor

brson commented May 10, 2013

@thestinger Can this be closed?

@thestinger
Copy link
Contributor Author

@brson: it's still an issue - the str module is encoding out-of-range utf-8

I just don't understand why std::json::from_str(~"\"") results in the proper assert failing.

The highest valid code point is 1114111 (0x10FFFF) and the modern UTF-8
standard guarantees that the maximum number of bytes needed to encode a
code point is 4 (instead of 6, in the legacy standard).

From <https://tools.ietf.org/html/rfc3629>:

Changes from RFC 2279

   o  Restricted the range of characters to 0000-10FFFF (the UTF-16
      accessible range).
@thestinger
Copy link
Contributor Author

Changing this into an issue, since it bitrotted.

@thestinger thestinger closed this Jun 5, 2013
bors added a commit to rust-lang-ci/rust that referenced this pull request May 2, 2020
Fix run-pass tests when CARGO_TARGET_DIR is not set

r? @lzutao

I got

```
thread '[ui] ui/crashes/ice-1969.rs' panicked at 'failed to exec `"target/debug/test_build_base/crashes/ice-1969.stage-id"`: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/pkrones/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/compiletest_rs-0.4.0/src/runtest.rs:1350:25
```

on tests with `// run-pass` locally. The reason for this is, that I haven't set `CARGO_TARGET_DIR` and then `"target"` was used as the `CARGO_TARGET_DIR`. It seems, that `compiletest-rs` cannot deal with relative paths for `// run-pass` tests.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants