Nomicon: Fix Links

The style `[name][]` does not work with Pandoc, whereas `[name]` does.
I hope hoedown accepts this as well.
pull/10/head
Pascal Hertleif 9 years ago committed by Manish Goregaokar
parent 4c56ec91c3
commit 83ce66888e

@ -52,7 +52,7 @@ impl<T> Drop for Box<T> {
``` ```
and this works fine because when Rust goes to drop the `ptr` field it just sees and this works fine because when Rust goes to drop the `ptr` field it just sees
a [Unique][] that has no actual `Drop` implementation. Similarly nothing can a [Unique] that has no actual `Drop` implementation. Similarly nothing can
use-after-free the `ptr` because when drop exits, it becomes inacessible. use-after-free the `ptr` because when drop exits, it becomes inacessible.
However this wouldn't work: However this wouldn't work:

@ -60,8 +60,8 @@ Unlike C, Undefined Behaviour is pretty limited in scope in Rust. All the core
language cares about is preventing the following things: language cares about is preventing the following things:
* Dereferencing null or dangling pointers * Dereferencing null or dangling pointers
* Reading [uninitialized memory][] * Reading [uninitialized memory]
* Breaking the [pointer aliasing rules][] * Breaking the [pointer aliasing rules]
* Producing invalid primitive values: * Producing invalid primitive values:
* dangling/null references * dangling/null references
* a `bool` that isn't 0 or 1 * a `bool` that isn't 0 or 1

@ -26,7 +26,7 @@ still consumes a byte of space.
* DSTs, tuples, and tagged unions are not a concept in C and as such are never * DSTs, tuples, and tagged unions are not a concept in C and as such are never
FFI safe. FFI safe.
* **If the type would have any [drop flags][], they will still be added** * **If the type would have any [drop flags], they will still be added**
* This is equivalent to one of `repr(u*)` (see the next section) for enums. The * This is equivalent to one of `repr(u*)` (see the next section) for enums. The
chosen size is the default enum size for the target platform's C ABI. Note that chosen size is the default enum size for the target platform's C ABI. Note that

@ -35,7 +35,7 @@ unchecked contracts:
There is also `#[unsafe_no_drop_flag]`, which is a special case that exists for There is also `#[unsafe_no_drop_flag]`, which is a special case that exists for
historical reasons and is in the process of being phased out. See the section on historical reasons and is in the process of being phased out. See the section on
[drop flags][] for details. [drop flags] for details.
Some examples of unsafe functions: Some examples of unsafe functions:
@ -44,7 +44,7 @@ Some examples of unsafe functions:
* `ptr::offset` is an intrinsic that invokes Undefined Behaviour if it is * `ptr::offset` is an intrinsic that invokes Undefined Behaviour if it is
not "in bounds" as defined by LLVM. not "in bounds" as defined by LLVM.
* `mem::transmute` reinterprets some value as having the given type, * `mem::transmute` reinterprets some value as having the given type,
bypassing type safety in arbitrary ways. (see [conversions][] for details) bypassing type safety in arbitrary ways. (see [conversions] for details)
* All FFI functions are `unsafe` because they can do arbitrary things. * All FFI functions are `unsafe` because they can do arbitrary things.
C being an obvious culprit, but generally any language can do something C being an obvious culprit, but generally any language can do something
that Rust isn't happy about. that Rust isn't happy about.

@ -10,7 +10,7 @@ captures this through the `Send` and `Sync` traits.
Send and Sync are fundamental to Rust's concurrency story. As such, a Send and Sync are fundamental to Rust's concurrency story. As such, a
substantial amount of special tooling exists to make them work right. First and substantial amount of special tooling exists to make them work right. First and
foremost, they're [unsafe traits][]. This means that they are unsafe to foremost, they're [unsafe traits]. This means that they are unsafe to
implement, and other unsafe code can assume that they are correctly implement, and other unsafe code can assume that they are correctly
implemented. Since they're *marker traits* (they have no associated items like implemented. Since they're *marker traits* (they have no associated items like
methods), correctly implemented simply means that they have the intrinsic methods), correctly implemented simply means that they have the intrinsic

@ -21,7 +21,7 @@ same size. The ways to cause Undefined Behaviour with this are mind boggling.
* No you can't do it * No you can't do it
* No you're not special * No you're not special
* Transmuting to a reference without an explicitly provided lifetime * Transmuting to a reference without an explicitly provided lifetime
produces an [unbounded lifetime][] produces an [unbounded lifetime]
`mem::transmute_copy<T, U>` somehow manages to be *even more* wildly unsafe than `mem::transmute_copy<T, U>` somehow manages to be *even more* wildly unsafe than
this. It copies `size_of<U>` bytes out of an `&T` and interprets them as a `U`. this. It copies `size_of<U>` bytes out of an `&T` and interprets them as a `U`.

Loading…
Cancel
Save