17 Unsafe Operations
All functions and forms provided by racket/base and
racket check their arguments to ensure that the
arguments conform to contracts and other constraints. For example,
vector-ref checks its arguments to ensure that the first
argument is a vector, that the second argument is an exact integer,
and that the second argument is between 0 and one less than
the vector’s length, inclusive.
Functions provided by racket/unsafe/ops are
unsafe. They have certain constraints, but the constraints
are not checked, which allows the system to generate and execute
faster code. If arguments violate an unsafe function’s constraints,
the function’s behavior and result is unpredictable, and the entire
system can crash or become corrupted.
All of the exported bindings of racket/unsafe/ops are
protected in the sense of protect-out, so access to unsafe
operations can be prevented by adjusting the code inspector (see
17.1 Unsafe Numeric Operations
: Like +
, but constrained to consume fixnums
and produce a
result. The mathematical operation on a
must be representable as a fixnum
. In the case of
must not be 0
: Like bitwise-and
, but constrained to consume fixnums
the result is always a fixnum
. The unsafe-fxlshift
operations correspond to
, but require non-negative arguments;
is a positive (i.e., left) shift, and
is a negative (i.e., right) shift, where the
number of bits to shift must be less than the number of bits used to
represent a fixnum
. In the case of unsafe-fxlshift
bits in the result beyond the number of bits used to represent a
are effectively replaced with a copy of the high bit.
: Unchecked (potentially) versions of
, and flexpt
. Currently, some of these
bindings are simply aliases for the corresponding safe bindings.
Unchecked conversion of a fixnum to an integer flonum and vice versa.
These are similar to the safe bindings ->fl
but further constrained to consume or produce a fixnum.
17.2 Unsafe Data Extraction
Unsafe variant of cons
that produces a pair that claims to be
without checking whether rest
is a list.
A vector’s size can never be larger than a fixnum, so even
vector-length always returns a fixnum.
Unsafe field access and update for an instance of a structure
type, where the struct*
variants can be
faster but do not work on impersonators
The index k
must be between 0
the number of fields in the structure (exclusive). In the case of
, the field must be mutable.
17.3 Unsafe Extflonum Operations
Unchecked (potentially) versions of extflsin
. Currently, some of these bindings are simply
aliases for the corresponding safe bindings.
17.4 Unsafe Undefined
The constant unsafe-undefined is used internally as a
placeholder value. For example, it is used by letrec as a
value for a variable that has not yet been assigned a value. Unlike
the undefined value exported by racket/undefined,
however, the unsafe-undefined value should not leak as the
result of a safe expression. Expression results that potentially
produce unsafe-undefined can be guarded by
check-not-unsafe-undefined, so that an exception can be
raised instead of producing an undefined value.
The unsafe-undefined value is always eq? to itself.
Added in version 184.108.40.206 of package base.
The unsafe “undefined” constant.
The same as check-not-unsafe-undefined
, except that the error
message (if any) is along the lines of “sym
assignment before initialization.”
if it is a structure (as viewed through some
). Every access of a field in the structure is checked
to prevent returning unsafe-undefined
. Similarly, every
assignment to a field in the structure is checked (unless the check
disabled as described below) to prevent assignment of a field whose
current value is unsafe-undefined
When a field access would otherwise produce unsafe-undefined
or when a field assignment would replace unsafe-undefined, the
exn:fail:contract exception is raised.
The chaperone’s field-assignment check is disabled whenever
(continuation-mark-set-first #f prop:chaperone-unsafe-undefined) returns unsafe-undefined.
Thus, a field-initializing assignment—one that is intended to replace the
unsafe-undefined value of a field—should be wrapped with
(with-continuation-mark prop:chaperone-unsafe-undefined unsafe-undefined ....).
The property value should be a list of symbols used as field names,
but the list should be in reverse order of the structure’s fields.
When a field access or assignment would produce or replace
unsafe-undefined, the exn:fail:contract:variable
exception is raised if a field name is provided by the structure
property’s value, otherwise the exn:fail:contract exception