Skip to content

Unsafetyify From<Vec<char>> - #35098

Closed
nagisa wants to merge 3 commits into
rust-lang:masterfrom
nagisa:unsafetyify-from-vec-char
Closed

Unsafetyify From<Vec<char>>#35098
nagisa wants to merge 3 commits into
rust-lang:masterfrom
nagisa:unsafetyify-from-vec-char

Conversation

@nagisa

Copy link
Copy Markdown
Member

Follow-up PR for #35054

@rust-highfive

Copy link
Copy Markdown
Contributor

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@nagisa
nagisaforce-pushed the unsafetyify-from-vec-char branch 2 times, most recently from 8c2706d to 8a5d5a2CompareJuly 28, 2016 21:26
Comment threadsrc/libcollections/string.rs Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What do you think about the suggestion from #35054 (comment)?
char usually implies that we work with human language so we can use domain knowledge.
len + len / 8(=1.125) or len + len / 16(=1.0625) cover most of European languages.
For reference,
ratio(en) ≈ 1.002
ratio(fr) ≈ 1.040
ratio(de) ≈ 1.016
ratio(hu) ≈ 1.091 (lots of diacritics)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

I’m really uninterested in tackling this implementation in this PR.

But since you’ve asked, I ought to state my opinion on the topic, at least. I agree that nobody would store ASCII-only text as UTF-32 (there’s bytestrings, after all) and any ratio > 1 is therefore better than ratio = 1. ratio = 1.5 to 1.6 coupled with the fact that reallocation doubles capacity could be a good choice, especially given the fact that ratio(jp), ratio(cn) and ratio(ko) are all somewhere between 2 and a bit over 3.

That being said, my gut tells me that nobody would be using this conversion with any serious expectations towards its performance, thus thinking about this problem is not very productive.

@alexcrichtonalexcrichton added the T-libs-api [DEPRECATED; DO NOT USE] label Jul 29, 2016
We know for sure this method cannot slice out-of-bounds because:
* 0 ≤ self.pos ≤ 3
* self.buf.len() = 4
This way the slicing will always succeed, but LLVM is incapable of figuring out both these
conditions hold, resulting in suboptimal code, especially after inlining.
Machine code turned out pretty nicely.
@nagisa
nagisaforce-pushed the unsafetyify-from-vec-char branch from 8a5d5a2 to 0ce9323CompareAugust 2, 2016 11:06
@sfackler

Copy link
Copy Markdown
Member

We discussed this at the libs triage, and @alexcrichton raised some soundness concerns. The allocator is provided with alignment information when deallocating the memory backing the String, which will be wrong in this case.

@nagisa

Copy link
Copy Markdown
MemberAuthor

Fair point. I feel like something like cap = __rust_reallocate_inplace(ptr, cap, cap, new_align) should be enough here, but I’m having serious trouble finding out any documentation on either jemalloc or rust allocation functions.

@alexcrichton do you think calling that function is a correct way to “realign” memory?

@alexcrichton

Copy link
Copy Markdown
Member

As far as I know I don't think we have a way to realign memory, unfortunately :(

@alexcrichton

Copy link
Copy Markdown
Member

Closing for now due to the unsafety concerns (and lack of knowledge of a solution to them), but feel free to reopen if a solution is thought of!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-libs-api[DEPRECATED; DO NOT USE]

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@nagisa@rust-highfive@sfackler@alexcrichton@petrochenkov@ollie27