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

Implement Arbitrary for CString #165

Closed
clarfonthey opened this issue Mar 22, 2017 · 3 comments
Closed

Implement Arbitrary for CString #165

clarfonthey opened this issue Mar 22, 2017 · 3 comments

Comments

@clarfonthey
Copy link

clarfonthey commented Mar 22, 2017

Would be nice to have. String's impl isn't quite the same.

@BurntSushi
Copy link
Owner

PR's are welcome for this.

@ThomasdenH
Copy link
Contributor

What would be the ideal implementation here? Using the String implementation with a null-character or random non-null bytes terminated by a null character? Or some combination of the two?

For example, based on a random variable, either add a valid UTF-8 character to the string or a random non-null byte. Finally, end the string with '\0'.

@BurntSushi
Copy link
Owner

Yeah, I think we probably want a mix. I believe the Arbitrary impl for String has some smarts to it, and it would be nice to reuse that. While perhaps not optimal, I think one possible implementation of this would be:

  • Flip a coin. If heads, call Vec<u8>::arbitrary() and strip all NUL bytes from the result (or replace them with random non-NUL bytes).
  • If tails, call String::arbitrary() and strip all NUL bytes from the result (or replace them with random non-NUL UTF-8 encoded Unicode scalar values).

BurntSushi pushed a commit that referenced this issue Dec 27, 2020
We add a little sophistication here for whether the CString is
completely valid UTF-8 or whether it's just an arbitrary mix of bytes.
(Excluding NUL of course.)

Fixes #165, Closes #257
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants