Remove the definition of "safe".

`stack_addr` and unrestricted loads and stores *can* be used with entirely
defined behavior. The sense in which they're not "safe" is only that it's
possible to misuse them. This subtlety wasn't captured in the definition
of "safe" here, so for now, just remove the definition so that it doesn't
cause confusion.
This commit is contained in:
Dan Gohman
2017-10-20 11:30:22 -07:00
parent f4b25ff058
commit 29a6ee77f3

View File

@@ -497,8 +497,8 @@ about because stack slots and offsets are fixed at compile time. For example,
the alignment of these stack memory accesses can be inferred from the offsets the alignment of these stack memory accesses can be inferred from the offsets
and stack slot alignments. and stack slot alignments.
It can be necessary to escape from the :term:`safety` of the restricted It's also possible to obtain the address of a stack slot, which can be used
instructions by taking the address of a stack slot. in :ref:`unrestricted loads and stores <memory>`.
.. autoinst:: stack_addr .. autoinst:: stack_addr
@@ -1113,15 +1113,6 @@ Glossary
intermediate representation. Cretonne's IR can be converted to text intermediate representation. Cretonne's IR can be converted to text
losslessly. losslessly.
safe
safety
Execution of exclusively defined behavior. Safe programs cannot
read, write, or execute memory outside of heaps, globals, stack
regions, and functions that have been explicitly provided to them. In
some instances, defined behavior can be nondeterministic, where the
specific behavior may vary among a bounded set of possibilities.
Execution of undefined behavior is unsafe.
stack slot stack slot
A fixed size memory allocation in the current function's activation A fixed size memory allocation in the current function's activation
frame. Also called a local variable. frame. Also called a local variable.