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

Move extra::c_vec to collections. #12469

Closed
wants to merge 1 commit into from
Closed

Move extra::c_vec to collections. #12469

wants to merge 1 commit into from

Conversation

omasanori
Copy link
Contributor

cc #8784

cc #8784

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
@huonw
Copy link
Member

huonw commented Feb 22, 2014

This seems a little like something that would be better suited to a "libffi" or something, since it's not really a datastructure itself.

I don't really know.

@omasanori
Copy link
Contributor Author

Then c_str, libc, etc. will move to libffi? Well, it sounds good to me.

I think libcffi is better if we do, since anyone may confuse libffi and libffi 😄

@alexcrichton
Copy link
Member

We could also revive the old name of crust. Additionally, @brson was thinking that we could have std::libc in its own crate, and this would definitely belong in that crate.

@brson, do you have an opinion on this?

@brson
Copy link
Contributor

brson commented Feb 23, 2014

Libffi sounds promising, though I don't know offhand what else goes there.

I do think libc deserves its own crate, so maybe c_vec goes there (I'm not sure what c_vec is)?

Let's try that.

This then raises questions about c_str.

@huonw
Copy link
Member

huonw commented Feb 24, 2014

cc #12514 for a similar suggestion.

so maybe c_vec goes there (I'm not sure what c_vec is)?

c_vec is a wrapper around a *T + a length to provide a convenient (and slightly safe) interface to treat it as a &[T] slice, useful for interacting with vectors passed back from FFI calls.

@omasanori
Copy link
Contributor Author

It seems that there is a consensus that collections is not the library which c_vec should belong to. Further discussion (including c_str?) should be done on other issue.

Feel free to reopen this if I overlooked something.

@omasanori omasanori closed this Feb 25, 2014
@omasanori omasanori deleted the c_vec branch February 25, 2014 02:51
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this pull request Mar 21, 2024
chore: fix some typos

Thank you for making Clippy better!

We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change.

It's also helpful for us that the lint name is put within backticks (`` ` ` ``),
and then encapsulated by square brackets (`[]`), for example:
```
changelog: [`lint_name`]: your change
```

If your PR fixes an issue, you can add `fixes #issue_number` into this
PR description. This way the issue will be automatically closed when
your PR is merged.

If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.

- \[x] Followed [lint naming conventions][lint_naming]
- \[ ] Added passing UI tests (including committed `.stderr` file)
- \[ ] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`

[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints

Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.

Delete this line and everything above before opening your PR.

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog:
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