The style `[name][]` does not work with Pandoc, whereas `[name]` does.
I hope hoedown accepts this as well.
```
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.
However this wouldn't work:
language cares about is preventing the following things:
* Dereferencing null or dangling pointers
-* Reading [uninitialized memory][]
-* Breaking the [pointer aliasing rules][]
+* Reading [uninitialized memory]
+* Breaking the [pointer aliasing rules]
* Producing invalid primitive values:
* dangling/null references
* a `bool` that isn't 0 or 1
* DSTs, tuples, and tagged unions are not a concept in C and as such are never
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
chosen size is the default enum size for the target platform's C ABI. Note that
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
-[drop flags][] for details.
+[drop flags] for details.
Some examples of unsafe functions:
* `ptr::offset` is an intrinsic that invokes Undefined Behaviour if it is
not "in bounds" as defined by LLVM.
* `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.
C being an obvious culprit, but generally any language can do something
that Rust isn't happy about.
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
-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
implemented. Since they're *marker traits* (they have no associated items like
methods), correctly implemented simply means that they have the intrinsic
* No you can't do it
* No you're not special
* 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
this. It copies `size_of<U>` bytes out of an `&T` and interprets them as a `U`.