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

accessing private fields is not safe, and io isn't scary #26603

Merged
merged 2 commits into from
Jun 27, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions src/doc/reference.md
Original file line number Diff line number Diff line change
@@ -1047,11 +1047,8 @@ This is a list of behavior not considered *unsafe* in Rust terms, but that may
be undesired.

* Deadlocks
* Reading data from private fields (`std::repr`)
* Leaks of memory and other resources
Copy link
Member

Choose a reason for hiding this comment

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

How does this interact with what it says 18 lines previously?

[Behavior considered undefined] Invalid values in primitive types, even in private fields/locals

Is it now ok in private fields, since private fields are not permitted to be read?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's fine to make a private mem::uninitialized as long as a public consumer can't observe it. Making a bool = 3 is still invalid, though.

Copy link
Member

Choose a reason for hiding this comment

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

What's the difference between a private field bool = 3, and the same field being mem::uninitialized? Presumably it's essentially illegal to read such a thing in both cases, but they should be fine to be "write only".

Copy link
Member

Choose a reason for hiding this comment

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

I think I answered my own question why it's not a good idea to allow (see forum).

* Exiting without calling destructors
* Sending signals
* Accessing/modifying the file system
* Integer overflow
- Overflow is considered "unexpected" behavior and is always user-error,
unless the `wrapping` primitives are used. In non-optimized builds, the compiler
7 changes: 2 additions & 5 deletions src/doc/trpl/unsafe.md
Original file line number Diff line number Diff line change
@@ -12,7 +12,7 @@ two contexts. The first one is to mark a function as unsafe:

```rust
unsafe fn danger_will_robinson() {
// scary stuff
// scary stuff
}
```

@@ -68,11 +68,8 @@ Whew! That’s a bunch of stuff. It’s also important to notice all kinds of
behaviors that are certainly bad, but are expressly _not_ unsafe:

* Deadlocks
* Reading data from private fields
* Leaks due to reference count cycles
* Leaks of memory or other resources
* Exiting without calling destructors
* Sending signals
* Accessing/modifying the file system
* Integer overflow

Rust cannot prevent all kinds of software problems. Buggy code can and will be