Supplying too few arguments to a function in an unsafe call.

Too few arguments means fewer arguments than the number of required parameters for the function.

Supplying too many arguments to a function in an unsafe call.

Too many arguments means more arguments than the number of required parameters plus the number of optional parameters; however, if the function uses &rest or &key, it is not possible for it to receive too many arguments.

The consequences are undefined if colon or at-sign modifiers are given to a directive in a combination not specifically described here as being meaningful.

~> terminates a ~<. The consequences of using it elsewhere are undefined.

The consequences are undefined if an attempt is made to transfer control to an exit point whose dynamic extent has ended.

[I don't understand. Review later.]

The consequences are undefined if the result of fully macroexpanding a form contains any circular list structure except in literal objects.

Once a string has been given as the string argument to intern in this situation where a new symbol is created, the consequences are undefined if a subsequent attempt is made to alter that string.

The consequences of attempting to use pprint-pop outside of pprint-logical-block are undefined.

The consequences are undefined if pprint-pop is executed outside of the dynamic extent of this pprint-logical-block.

When writing[1] the value of any pathname component, the consequences are undefined if :unspecific is given for a pathname in a file system for which it does not make sense.

~) terminates a ~(. The consequences of using it elsewhere are undefined.

The consequences are undefined if literal objects (including self-evaluating objects) are destructively modified.

The consequences are undefined if list is a circular list.

The consequences are undefined if any accessor-name is not the name of an accessor for the instance.

The consequences are undefined if the local function named name established by with-hash-table-iterator is called after it has returned false as its primary value.

The consequences are undefined if literal objects are destructively modified. For this purpose, the following operations are considered destructive: [...]

The consequences are undefined if any component of a composite stream is closed before the composite stream is closed.

The consequences are undefined if the synonym stream symbol is not bound to an open stream from the time of the synonym stream's creation until the time it is closed.

The consequences are undefined if any slot-name is not the name of a slot in the instance.

if initial-element is not provided, the consequences of later reading any such new element of new-array before it has been initialized are undefined.

The consequences are undefined if instance has any other metaclass [than standard-class or built-in-class]--an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

The consequences are undefined if name is a special operator.

If destination is a string with a fill pointer, the consequences are undefined if destructive modifications are performed directly on the string during the dynamic extent of the call.

Every symbol has a name, and the consequences are undefined if that name is altered.

The consequences are undefined if an attempt is made to alter the home package of a symbol external in the COMMON-LISP package or the KEYWORD package.

The consequences are undefined if an attempt is made to change the value of a symbol that names a constant variable, or to make such a symbol be unbound.

The consequences are undefined if an attempt is made to change the functional value of a symbol that names a special form.

The consequences are undefined if environment is non-nil in a use of setf of macro-function.

The consequences are undefined if a macro function destructively modifies any part of its form argument.

The first argument to update-instance-for-different-class, previous, is that copy; it holds the old slot values temporarily. This argument has dynamic extent within change-class; if it is referenced in any way once update-instance-for-different-class returns, the results are undefined.

pprint-logical-block and the pretty printing stream it creates have dynamic extent. The consequences are undefined if, outside of this extent, output is attempted to the pretty printing stream it creates.

It is also unspecified what happens if, within this extent, any output is sent directly to the underlying destination stream.

[3 examples of code having undefined consequences.]

The environment object has dynamic extent; the consequences are undefined if the environment object is referred to outside the dynamic extent of the macro expansion function.

~] terminates a ~[. The consequences of using it elsewhere are undefined.

The consequences are undefined if an attempt is made to assign the the variable var with the forms.

~} terminates a ~{. The consequences of using it elsewhere are undefined.

The consequences are undefined if the type-specifier is not a type specifier.

The consequences are undefined if an attempt is made to assign the variable var.

The consequences are undefined if destructive modifications are performed directly on the string during the dynamic extent of the call.

[An example of code with undefined behavior.]

The consequences are undefined if both tree-1 and tree-2 are circular.

The consequences are undefined if the token immediately following the #X does not have the syntax of a hexadecimal (i.e., radix 16) rational.

The consequences are undefined if stream-output-string is closed.

The consequences are undefined if string-output-stream is a stream that was not produced by make-string-output-stream. The consequences are undefined if string-output-stream was created implicitly by with-output-to-string or format.

For the input operations clear-input listen, peek-char, read-byte, read-char-no-hang, read-char, read-line, and unread-char, the consequences are undefined if the indicated operation is performed. However, an implementation is permitted to define such a behavior as an implementation-dependent extension.

The consequences are undefined if a program violates a declaration or a proclamation.

The consequences are undefined if list is a circular list.

The consequences are undefined if a type-spec argument is supplied for var if the related expression returns a value that is not of the supplied type.

The consequences are undefined if the token immediately following the #nR does not have the syntax of a rational in radix n.

The consequences are undefined if an attempt is made to modify the standard readtable.

The &environment argument has dynamic extent; the consequences are undefined if the &environment argument is referred to outside the dynamic extent of the macro expansion function.

The results are undefined if the user attempts to change or remove the class associated with a symbol that is defined as a type specifier in this standard.

[Several undefined sharpsign dispatch chars.]

a programmer must not use change-class inside a method if any methods for that generic function access any slots, or the results are undefined.

(In the notes section, which is technically not normative...)

Except as explicitly specified otherwise, the consequences are undefined if this type restriction is violated.

Within a function named F, the compiler may (but is not required to) assume that an apparent recursive call to a function named F refers to the same definition of F, unless that function has been declared notinline. The consequences of redefining such a recursively defined function F while it is executing are undefined.

Type declarations present in the compilation environment must accurately describe the corresponding values at run time; otherwise, the consequences are undefined. It is permissible for an unknown type to appear in a declaration at compile time, though a warning might be signaled in such a case.

The consequences are undefined if char has a syntax type of whitespace[2] in the current readtable.

Except where explicitly allowed, the consequences are undefined if any of the following actions are performed on an external symbol of the COMMON-LISP package: [...]

The consequences are undefined if new-name or any new-nickname conflicts with any existing package names.

The consequences are undefined if the number of objects specified before the closing ) exceeds the unsigned decimal integer.

The consequences are undefined if the unsigned decimal integer is non-zero and number of objects supplied before the closing ) is zero.

The consequences of attempting to store in a slot a value that does not satisfy the type of the slot is undefined.

Except as explicitly specified otherwise, the consequences are undefined when a closed stream is used where a stream is called for.

A constant defined by defconstant can be redefined with defconstant. However, the consequences are undefined if an attempt is made to assign a value to the symbol using another operator, or to assign it to a different value using a subsequent defconstant.

The consequences are undefined if there are any bindings of the variable named by name at the time defconstant is executed or if the value is not eql to the value of initial-value.

The consequences are undefined when constant symbols are rebound as either lexical or dynamic variables. In other words, a reference to a symbol declared with defconstant always refers to its global value.

[An example of undefined behavior.]

The consequences are undefined if keys and data are not of the same length.

The consequences are undefined if package is the KEYWORD package or the COMMON-LISP package.

The consequences are undefined if a format directive is given more parameters than it is described here as accepting.

The consequences are undefined if at any time the value of any of these variables is not an open stream.

If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition.

Destructively modifying a &rest list.

When the function receives its arguments via &rest, it is permissible (but not required) for the implementation to bind the rest parameter to an object that shares structure with the last argument to apply. Because a function can neither detect whether it was called via apply nor whether (if so) the last argument to apply was a constant, conforming programs must neither rely on the list structure of a rest list to be freshly consed, nor modify that list structure.

The macro-expansion functions defined by macrolet are defined in the lexical environment in which the macrolet form appears. Declarations and macrolet and symbol-macrolet definitions affect the local macro definitions in a macrolet, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that lexical environment.

Supplying an unrecognized keyword argument to a function in an unsafe call without suppression of keyword argument checking either on the callee side with &allow-other-keys or on the caller side with :allow-other-keys t.

The consequences are undefined if the implementation does not provide a resident editor.

The purpose of endp is to test for the end of proper list. Since endp does not descend into a cons, it is well-defined to pass it a dotted list. However, if shorter ``lists'' are iteratively produced by calling cdr on such a dotted list and those ``lists'' are tested with endp, a situation that has undefined consequences will eventually result when the non-nil atom (which is not in fact a list) finally becomes the argument to endp.

(In the notes section, which is technically not normative...)

invoke-restart-interactively prompts for arguments by executing the code provided in the :interactive keyword to restart-case or :interactive-function keyword to restart-bind.

If no such options have been supplied in the corresponding restart-bind or restart-case, then the consequences are undefined if the restart takes required arguments. If the arguments are optional, an argument list of nil is used.

The consequences are undefined if an attempt is made to assign a value to, or create a binding for a constant variable, except that a `compatible' redefinition of a constant variable using defconstant is permitted; see the macro defconstant.

The consequences are undefined if there is no matching tag lexically visible to the point of the go.

The consequences are undefined if the list structure of the streams is ever modified.

[Important details about function types.]

Except as explicitly stated otherwise, for any standardized function that takes a parameter that is required to be a tree, the consequences are undefined if that tree is circular.

Methods on describe-object can recursively call describe. Indentation, depth limits, and circularity detection are all taken care of automatically, provided that each method handles exactly one level of structure and calls describe recursively if there are more structural levels. The consequences are undefined if this rule is not obeyed.

the consequences are undefined if base-number is zero when power-number is zero and not of type integer.

The consequences of writing a compiler macro definition for a function in the COMMON-LISP package are undefined;

(In the notes section, which is technically not normative...)

The consequences are undefined if environment is non-nil in a use of setf of compiler-macro-function.

The consequences are undefined when code executed during an object-traversing operation destructively modifies the object in a way that might affect the ongoing traversal operation. In particular, the following rules apply. [...]

[A few undefined patterns for tokens.]

The consequences are undefined if no arg remains for a directive requiring an argument. However, it is permissible for one or more args to remain unprocessed by a directive; such args are ignored.

This separates clauses in ~[ and ~< constructs. The consequences of using it elsewhere are undefined.

The consequences are undefined if the local function named name established by with-package-iterator is called after it has returned false as its primary value.

The consequences are undefined if no definition is supplied when the name is nil.

The consequences are undefined if the lexical environment surrounding the function to be compiled contains any bindings other than those for macros, symbol macros, or declarations.

(!)

The consequences are undefined if an attempt is made to assign the variable var.

Except as explicitly indicated otherwise, implementations are not required to detect attempts to modify immutable objects or cells; the consequences of attempting to make such modification are undefined.

A conforming implementation is encouraged (but not required) to document its treatment of each item in this specification which is marked implementation-dependent, although in some cases such documentation might simply identify the item as ``undefined.''

If no default value is supplied for an aux variable variable, the consequences are undefined if an attempt is later made to read the corresponding slot's value before a value is explicitly assigned.

The consequences of deleting the COMMON-LISP package or the KEYWORD package are undefined.

The consequences of attempting to use call-method outside of an effective method form are undefined.

The consequences are undefined if the token immediately following the #O does not have the syntax of an octal (i.e., radix 8) rational.

The order in which the keys are accessed is undefined;

The consequences are undefined if any result is not of the declared type.

The consequences are undefined if the values yielded by the form are not of the type specified by value-type.

Except as explicitly specified otherwise, for any standardized function that takes a parameter that is required to be a list, the consequences are undefined if that list is circular.

* If the datum is a condition ... The denoted condition is the datum itself. In this case, unless otherwise specified by the description of the operator in question, the arguments must be null; that is, the consequences are undefined if any arguments were supplied.

The consequences of attempting to use next-method-p outside of a method-defining form are undefined.

The consequences are undefined if literal objects (including quoted objects) are destructively modified.

The consequences of the following are undefined [...] [an example]

(In the examples section, which is technically not normative...)

The consequences are undefined if a compiler macro function destructively modifies any part of its form argument.

the consequences are undefined if a character is inserted into a string for which the element type of the string does not include that character.

The consequences of attempting to use call-next-method outside of a method-defining form are undefined.

Implementations are permitted, but not required, to return distinct lists from repeated calls to compute-restarts while in the same dynamic environment. The consequences are undefined if the list returned by compute-restarts is every (sic) modified.

If no slot-initform is supplied, the consequences are undefined if an attempt is later made to read the slot's value before a value is explicitly assigned.

The consequences of redefining a defstruct structure are undefined.

The consequences are undefined if the included-structure-name does not name a structure type.

The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined.

When matching a destructuring lambda list against a form, the pattern and the form must have compatible tree structure [...] Otherwise, [...] in an unsafe call the situation has undefined consequences.

The contents of a slot will always be of type (and T1 ... Tn) where T1 ...Tn are the values of the :type slot options contained in all of the slot specifiers. If no slot specifier contains the :type slot option, the contents of the slot will always be of type t. The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined.

A consequence of the type rule is that the value of a slot satisfies the type constraint of each slot specifier that contributes to that slot. Because the result of attempting to store in a slot a value that does not satisfy the type constraint for the slot is undefined, the value in a slot might fail to satisfy its type constraint.

If initial-element is not supplied, the consequences of later reading an uninitialized element of new-array are undefined unless either initial-contents is supplied or displaced-to is non-nil.

If initial-contents is not supplied, the consequences of later reading an uninitialized element of new-array are undefined unless either initial-element is supplied or displaced-to is non-nil.

If displaced-to is non-nil, make-array will create a displaced array and displaced-to is the target of that displaced array. In that case, the consequences are undefined if the actual array element type of displaced-to is not type equivalent to the actual array element type of the array being created.

The order of evaluation of default value forms for initialization arguments and the order of evaluation of :initform forms are undefined. If the order of evaluation is important, initialize-instance or shared-initialize methods should be used instead.

The consequences are undefined if a symbol is used as a function designator but it does not have a global definition as a function, or it has a global definition as a macro or a special form.

If execution of the body affects which symbols are contained in the set of packages over which iteration is occurring, other than to remove the symbol currently the value of var by using unintern, the consequences are undefined.

Supplying an odd number of keyword arguments to a function in an unsafe call without suppression of keyword argument checking either on the callee side with &allow-other-keys or on the caller side with :allow-other-keys t.

The consequences are undefined if an attempt is made to assign the stream variable. The compiler may choose to issue a warning if such an attempt is detected.

The consequences of trying to use a declare expression as a form to be evaluated are undefined.

The consequences are undefined if instance has any other metaclass [than standard-class or built-in-class]--an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

The consequences are undefined if the result of applying function to the successive elements of the sequences cannot be contained in a sequence of the type given by result-type.

Supplying a keyword argument to a function using a name that is not a symbol in an unsafe call without suppression of keyword argument checking either on the callee side with &allow-other-keys or on the caller side with :allow-other-keys t.

`,@form has undefined consequences.

`(x1 x2 x3 ... xn . ,@form) has undefined consequences.

The consequences of attempting to use loop-finish outside of loop are undefined.

During the execution of any reference to the declared variable within the scope of the declaration, the consequences are undefined if the value of the declared variable is not of the declared type.

During the execution of any setq of the declared variable within the scope of the declaration, the consequences are undefined if the newly assigned value of the declared variable is not of the declared type.

At the moment the scope of the declaration is entered, the consequences are undefined if the value of the declared variable is not of the declared type.

The consequences are undefined if filespec has a wild component, or if filespec has a nil component and the file system does not permit a nil component.

error n. 1. (only in the phrase ``is an error'') a situation in which the semantics of a program are not specified, and in which the consequences are undefined.

The consequences are undefined if a function name is used as an extended function designator but it does not have a global definition as a function, or if it is a symbol that has a global definition as a macro or a special form.

Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated.

The consequences of attempting to use pprint-exit-if-list-exhausted outside of pprint-logical-block are undefined.

the consequences of executing pprint-if-list-exhausted (sic) outside of the dynamic extent of the pprint-logical-block which lexically contains it are undefined.

Methods on print-object are responsible for implementing their part of the semantics of the printer control variables, as follows: [...] If these rules are not obeyed, the results are undefined.

It is implementation-dependent whether the string that becomes the new-symbol's name is the given name or a copy of it. Once a string has been given as the name argument to make-symbol, the consequences are undefined if a subsequent attempt is made to alter that string.

The consequences are undefined if the token immediately following the #B does not have the syntax of a binary (i.e., radix 2) rational.

Using setf on a form obtained with the :arguments option.

The consequences are undefined if name is ever modified.

The consequences are undefined if the result of fully expanding a type specifier contains any circular structure, except within the objects referred to by member and eql type specifiers.

[An example of unspecified behavior.]

There are two situations in which a compiler macro definition must not be applied by any language processor: [...] It is unspecified whether compiler macros are expanded or used in any other situations.

Attempting to read from or write to a slot for an object that doesn't have a slot with that name and that has a metaclass other than standard-class or built-in-class.

an error might or might not be signaled in this situation. Note in particular that the behavior for conditions and structures is not specified.

The consequences are unspecified if a quality appears more than once with different values.

The consequences are unspecified if more than one such documentation string is present.

It is unspecified what happens if any of the implicit interior state of an iteration is returned outside the dynamic extent of the with-hash-table-iterator form such as by returning some closure over the invocation form.

The consequences are unspecified if a type declaration is specified for a var, but the value to which that var is bound is not consistent with the type declaration.

symbol: In order to guarantee that compiled files can be loaded correctly, users must ensure that the packages referenced in those files are defined consistently at compile time and load time. Conforming programs must satisfy the following requirements: [...] If any of these conditions do not hold, the package in which the loader looks for the affected symbols is unspecified. Implementations are permitted to signal an error or to define this behavior.

The consequences are unspecified if an unnamed restart is specified but no :report option is provided.

element-type specifies the type of the elements of the resulting array. If element-type is supplied, the consequences are unspecified if the upgraded array element type of element-type is not the same as the actual array element type of array.

(!)

The consequences are unspecified if array is adjusted to a size smaller than its fill pointer without supplying the fill-pointer argument so that its fill-pointer is properly adjusted in the process.

If A is displaced to B, the consequences are unspecified if B is adjusted in such a way that it no longer has enough elements to satisfy A.

As with other defining macros, it is unspecified whether or not the compile-time side-effects of a declaim persist after the file has been compiled.

Conforming code shall not depend on the consequences of undefined or unspecified situations.

pprint-logical-block and the pretty printing stream it creates have dynamic extent. The consequences are undefined if, outside of this extent, output is attempted to the pretty printing stream it creates.

It is also unspecified what happens if, within this extent, any output is sent directly to the underlying destination stream.

When an error goes undetected, the effects can be implementation-dependent, implementation-defined, unspecified, or undefined.

The consequences are unspecified if any argument other than the first is zero.

If there is only one argument, the consequences are unspecified if it is zero.

The consequences of using characters other than those specified here in a logical pathname namestring are unspecified.

The consequences of using any value not specified here as a logical pathname component are unspecified.

It is unspecified whether a definition available in the compilation environment can be used in an evaluation initiated in the startup environment or evaluation environment.

A call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file.

The consequences of the use of notation such as :1, :1/2, and :2^3 in a position where an expression appropriate for read is expected are unspecified.

[TODO]

The consequences are unspecified if an attempt is made to assign or bind either of these variables.

A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard, or a documented consequence of a situation that the standard specifies as undefined, unspecified, or extendable by the implementation. For example, if this standard says that ``the results are unspecified,'' an extension would be to specify the results.

The consequences are unspecified if an attempt is made to assign the slots by using setf.

The consequences are unspecified if any attempt is made to add or remove an entry from the hash-table while a maphash is in progress, with two exceptions: the function can use can use setf of gethash to change the value part of the entry currently being processed, or it can use remhash to remove that entry.

If an object O1 is used as a key in a hash table H and is then visibly modified with regard to the equivalence test of H, then the consequences are unspecified if O1, or any object O2 equivalent to O1 under the equivalence test (either before or after the modification), is used as a key in further operations on H. The consequences of using O1 as a key are unspecified even if O1 is visibly modified and then later modified again in such a way as to undo the visible modification.

Two hash tables S and C are similar if they meet the following three requirements: [...] If there is more than one possible one-to-one correspondence between the keys of S and C, the consequences are unspecified. A conforming program cannot use a table such as S as an externalizable constant.

Consider a declaration of the following form: [...] This declaration has the interpretation that, within the scope of the declaration, the consequences are unspecified if the value of fn-valued-variable is called with arguments not of the specified types; the value resulting from a valid call will be of type val-type.

The reason for making the return values for describe-object unspecified is to avoid forcing users to include explicit (values) in all of their methods. describe takes care of that.

(In the notes section, which is technically not normative...)

Although anonymous restarts have a name of nil, the consequences are unspecified if nil is given as an identifier. Occasionally, programmers lament that nil is not permissible as an identifier argument. In most such cases, compute-restarts can probably be used to simulate the desired effect.

(In the notes section, which is technically not normative...)

For a stream created with make-string-output-stream, the result of get-output-stream-string is unspecified after close.

If the second argument specifies a name that does not correspond to any slots accessible in the instance, the results are unspecified.

A summary of rules concerning package markers follows. [...] The consequences are unspecified if any other pattern of package markers in a token is used. All other uses of package markers within names of symbols are not defined by this standard but are reserved for implementation-dependent use.

It is unspecified whether symbols inherited from multiple packages are returned more than once. The order of symbols returned does not necessarily reflect the order of packages in package-list. When package-list has more than one element, it is unspecified whether duplicate symbols are returned once or more than once.

It is unspecified what happens if any of the implicit interior state of an iteration is returned outside the dynamic extent of the with-package-iterator form such as by returning some closure over the invocation form.

Invoking peek-char or read-char commits all previous characters. The consequences of invoking unread-char on any character preceding that which is returned by peek-char (including those passed over by peek-char that has a non-nil peek-type) are unspecified. In particular, the consequences of invoking unread-char after peek-char are unspecified.

implementation-dependent adj. describing a behavior or aspect of Common Lisp which has been deliberately left unspecified, that might be defined in some conforming implementations but not in others, and whose details may differ between implementations. A conforming implementation is encouraged (but not required) to document its treatment of each item in this specification which is marked implementation-dependent, although in some cases such documentation might simply identify the item as ``undefined.''

If the list is a circular list, tailp will reliably yield a value only if the given object is in fact a tail of list. Otherwise, the consequences are unspecified: a given implementation which detects the circularity must return false, but since an implementation is not obliged to detect such a situation, tailp might just loop indefinitely without returning in that case.

(In the notes section, which is technically not normative...)

The consequences of invoking any other package operation [than packagep or package-name] on package once it has been deleted are unspecified. In particular, the consequences of invoking find-symbol, intern and other functions that look for a symbol name in a package are unspecified if they are called with *package* bound to the deleted package or with the deleted package as an argument.

The generic function allocate-instance creates and returns a new instance of the class, without initializing it. When the class is a standard class, this means that the slots are unbound; when the class is a structure class, this means the slots' values are unspecified.

The consequences of adding methods to allocate-instance is unspecified. This capability might be added by the Metaobject Protocol.

The consequences are unspecified if a special declaration is made for symbol while in the scope of this definition (i.e., when it is not shadowed[2] by a binding for a variable or symbol macro named by the same symbol).

For for count, maximize, minimize, and sum:

If into var is used, a type can be supplied for var with the type-spec argument; the consequences are unspecified if a nonnumeric type is supplied.

If the maximize or minimize clause is never executed, the accumulated value is unspecified.

When a symbol is to be located in a given package the following occurs: [...] The external symbols of the used packages are searched in some unspecified order. The order does not matter; see the rules for handling name conflicts listed below.

Note that top level forms are processed in the order in which they textually appear in the file and that each top level form read by the compiler is processed before the next is read. However, the order of processing (including macro expansion) of subforms that are not top level forms and the order of further compilation is unspecified as long as Common Lisp semantics are preserved.

When an array A is given as the :displaced-to argument to make-array when creating array B [...] The consequences are unspecified if the total size of A is smaller than the sum of the total size of B plus the offset n supplied by the displaced-index-offset.

The consequences are unspecified if packages denoted by use do not exist.

While some Common Lisp operations might signal storage-condition because they are defined to create objects, it is unspecified whether operations that are not defined to create objects create them anyway and so might also signal storage-condition. [...]

The stream variables established by with-open-file, with-open-stream, with-input-from-string, and with-output-to-string, and all iteration variables are, by definition, always ``used''. Using (declare (ignore v)), for such a variable v has unspecified consequences.

(!)

The consequences are unspecified if a character is written that cannot be represented by the given external file format.

The consequences are unspecified if an attempt is made to assign or bind either of these variables.

[...] Where these rules do not uniquely determine an order of evaluation between two creation/initialization forms, the order of evaluation is unspecified.

The consequences are unspecified if both a :test and a :test-not argument are supplied in the same call to F.

In the process of parsing a symbol, it is implementation-dependent which implementation-defined attributes are removed from the characters forming a token that represents a symbol.

Whether separator characters are permitted as part of a string in a pathname component is implementation-defined; however, if the implementation does permit it, it must arrange to properly ``quote'' the character for the file system when constructing a namestring.

If dribble is called while a stream to a ``dribble file'' is still open from a previous call to dribble, the effect is implementation-defined. For example, the already-open stream might be closed, or dribbling might occur both to the old stream and to a new one, or the old stream might stay open but not receive any further output, or the new request might be ignored, or some other action might be taken.

No other standardized function is required to be supported, but an implementation may define such support. An implementation may also define support for implementation-defined operators.

These constant variables provide a way for programs to examine the implementation-defined limits for the various float formats.

Whether a value of :unspecific is permitted for any component on any given file system accessible to the implementation is implementation-defined.

The nature of the mapping between structure imposed by pathnames and the structure, if any, that is used by the underlying file system is implementation-defined.

The mapping of the pathname components into the concepts peculiar to each file system is implementation-defined.

there might [...] be implementation-defined printer control variables.

There may be other, implementation-defined optimize qualities.

Additional, implementation-defined attributes of characters are also permitted so that, for example, two characters with the same code may differ in some other, implementation-defined way.

For any implementation-defined attribute there is a distinguished value called the null value for that attribute. A character for which each implementation-defined attribute has the null value for that attribute is called a simple character. If the implementation has no implementation-defined attributes, then all characters are simple characters.

For each parameter, the argument supplied must be in the intersection of the type specified in the description of the corresponding generic function and the type given in the signature of some method (including not only those methods defined in this specification, but also implementation-defined or user-defined methods in situations where the definition of such methods is permitted).

In general, the syntax of namestrings involves the use of implementation-defined conventions, usually those customary for the file system in which the named file resides.

An implementation may be extended to accept implementation-defined keyword arguments to directory.

The effect of changing the value of *terminal-io*, either by binding or assignment, is implementation-defined.

An error is a situation in which normal program execution cannot continue correctly without some form of intervention (either interactively by the user or under program control). Not all errors are detected. When an error goes undetected, the effects can be implementation-dependent, implementation-defined, unspecified, or undefined.

The nature and format of the printed information is implementation-defined.

The functions input-stream-p and interactive-stream-p return an implementation-defined, generalized boolean value.

output-file---a pathname designator. The default is implementation-defined.

Any implementation-defined character that has case must be alphabetic[1]. For each implementation-defined graphic character that has no case, it is implementation-defined whether that character is alphabetic[1].

A ``wildcard field'' is a pathname component with a value of :wild, a :wild element of a list-valued directory component, or an implementation-defined portion of a component, such as the "*" in the complex wildcard string "foo*bar" that some implementations support. An implementation that adds other wildcard features, such as regular expressions, must define how translate-pathname extends to those features.

The portion of source that is copied into the resulting pathname is implementation-defined.

During the copying of a portion of source into the resulting pathname, additional implementation-defined translations of case or file naming conventions might occur, especially when from-wildcard and to-wildcard are for different hosts.

If character has no implementation-defined attributes, the results of char-int and char-code are the same.

The number of such sets and boundaries between them is implementation-defined. Common Lisp does not require these sets to be types, but an implementation is permitted to define such types as an extension. Since no character from one script can ever be a member of another script, it is generally more useful to speak about character repertoires.

A character is sometimes represented merely by its code, and sometimes by another integer value which is composed from the code and all implementation-defined attributes (in an implementation-defined way that might vary between Lisp images even in the same implementation).

The precise meaning of an interactive stream is implementation-defined, and may depend on the underlying operating system.

There may be additional (implementation-defined) compile-time or run-time side effects, as long as such effects do not interfere with the correct operation of conforming programs.

A fixnum is an integer whose value is between most-negative-fixnum and most-positive-fixnum inclusive. Exactly which integers are fixnums is implementation-defined. The type fixnum is required to be a supertype of (signed-byte 16).

char= returns true if all characters are the same; otherwise, it returns false. If two characters differ in any implementation-defined attributes, then they are not char=.

If two characters have identical implementation-defined attributes, then their ordering by char< is consistent with the numerical ordering by the predicate char< on their codes.

char-equal, char-not-equal, char-lessp, char-greaterp, char-not-greaterp, and char-not-lessp are similar to char=, char/=, char<, char>, char<=, char>=, respectively, except that they ignore differences in case and might have an implementation-defined behavior for non-simple characters. For example, an implementation might define that char-equal, etc. ignore certain implementation-defined attributes. The effect, if any, of each implementation-defined attribute upon these functions must be specified as part of the definition of that attribute.

The specific nature of the interaction, including which I/O streams are used and whether the stepping has lexical or dynamic scope, is implementation-defined.

A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard, or a documented consequence of a situation that the standard specifies as undefined, unspecified, or extendable by the implementation.

It is permissible for other (implementation-defined) classes to appear in the implementation's class precedence list for the class.

The top level loop is not completely specified; thus the user interface is implementation-defined.

The logical pathname host name "SYS" is reserved for the implementation. The existence and meaning of SYS: logical pathnames is implementation-defined.

Other symbols [than nil, :unspecific and :wild] and integers have implementation-defined meaning.

A conforming implementation shall be accompanied by a document that provides a definition of all implementation-defined aspects of the language defined by this specification.

(Does any existing implementation actually do this??)

Common Lisp specifies input and output with respect to a non-interactive stream model. The specific details of how interactive input and output are mapped onto that non-interactive model are implementation-defined.

Sometimes, the non-interactive stream model calls for a newline. How that newline character is interactively entered is an implementation-defined detail of the user interface [...]

debugger n. a facility that allows the user to handle a condition interactively. For example, the debugger might permit interactive selection of a restart from among the active restarts, and it might perform additional implementation-defined services for the purposes of debugging.

derived type n. a type specifier which is defined in terms of an expansion into another type specifier. deftype defines derived types, and there may be other implementation-defined operators which do so as well.

If x is a function name, the text of its definition is edited. The means by which the function text is obtained is implementation-defined.

printer control variable n. a variable whose specific purpose is to control some action of the Lisp printer; that is, one of the variables in Figure 22-1, or else some implementation-defined variable which is defined by the implementation to be a printer control variable.

Implementations providing additional, implementation-defined attributes must define whether and how non-simple characters can be regarded as similar.

The result only ever differs from character in its code attribute; all implementation-defined attributes are preserved.

~C prints the character as if by using write-char if it is a simple character. Characters that are not simple are not necessarily printed as if by write-char, but are displayed in an implementation-defined, abbreviated format.

~:C is the same as ~C for printing characters, but other characters are ``spelled out.'' [...] For characters that are not simple and not printing, what is spelled out is implementation-defined.

Within the dynamic extent of the body of forms, all reader/printer control variables, including any implementation-defined ones not specified by this standard, are bound to values that produce standard read/print behavior.

Returns the host's list of translations. Each translation is a list of at least two elements: from-wildcard and to-wildcard. Any additional elements are implementation-defined.

output-file---a pathname designator. The default is implementation-defined.

The defaults for the output-file are taken from the pathname that results from merging the input-file with the value of *default-pathname-defaults*, except that the type component should default to the appropriate implementation-defined default type for compiled files.

The precise definition of these categories is implementation-defined.

No upper bound is specified for the number of characters in the base-char repertoire; the size of that repertoire is implementation-defined. The lower bound is 96, the number of standard characters.

I/O customization variable n. one of the stream variables in the next figure, or some other (implementation-defined) stream variable that is defined by the implementation to be an I/O customization variable.

implementation-defined adj. implementation-dependent, but required by this specification to be defined by each conforming implementation and to be documented by the corresponding implementor.

internal time unit n. a unit of time equal to 1/n of a second, for some implementation-defined integer value of n. See the variable internal-time-units-per-second.

iteration form n. a compound form whose operator is named in the next figure, or a compound form that has an implementation-defined operator and that is defined by the implementation to be an iteration form.

If *print-readably* is true, the vector prints in an implementation-defined manner; see the variable *print-readably*.

An implementation is free to support other (implementation-defined) declaration identifiers as well.

There are several (overlapping) categories of characters that have no formally associated type but that are nevertheless useful to name. They include [...] For each implementation-defined attribute of a character, the documentation for that implementation must specify whether characters that differ only in that attribute are permitted to differ in whether are not they are members of one of the aforementioned categories.

Consider this example, which describes how destruct processes its :constructor option. [...] The e slot is not initialized; its initial value is implementation-defined.

sequence function n. one of the functions in Figure 17-1, or an implementation-defined function that operates on one or more sequences. and that is defined by the implementation to be a sequence function.

simple adj. 1. (of an array) being of type simple-array. 2. (of a character) having no implementation-defined attributes, or else having implementation-defined attributes each of which has the null value for that attribute.

For each implementation-defined graphic character that has no case, the implementation must define whether or not it is a numeric character.

If two characters have the same implementation-defined attributes, then their ordering by char< is consistent with the numerical ordering by the predicate < on their code attributes.

the ordering or possible interleaving of uppercase characters and lowercase characters is implementation-defined.

Note that of the standardized method-defining operators only defgeneric can specify generic function options. defgeneric and any implementation-defined operators that can specify generic function options are also referred to as ``operators that specify generic function options.''

All non-graphic characters are required to have names unless they have some implementation-defined attribute which is not null.

namestring n. a string that represents a filename using either the standardized notation for naming logical pathnames described in Section 19.3.1 (Syntax of Logical Pathname Namestrings), or some implementation-defined notation for naming a physical pathname.

null [...] c. (of an implementation-defined attribute of a character) An object to which the value of that attribute defaults if no specific value was requested.

If *print-readably* is true, the array prints in an implementation-defined manner; see the variable *print-readably*. In particular, this may be important for arrays having some dimension 0.

[The COMMON-LISP-USER package] can use other implementation-defined packages.

(!)

uppercase adj. (of a character) being among standard characters corresponding to the capital letters A through Z, or being some other implementation-defined character that is defined by the implementation to be uppercase. See Section 13.1.4.3 (Characters With Case).

Other, implementation-defined packages might be present in the initial Common Lisp environment.

An implementation may define that other implementation-defined graphic characters have case. Such definitions must always be done in pairs---one uppercase character in one-to-one correspondence with one lowercase character.

wild adj. 1. (of a namestring) using an implementation-defined syntax for naming files, which might ``match'' any of possibly several possible filenames, and which can therefore be used to refer to the aggregate of the files named by those filenames.

Searches for and loads the definition of a logical host named host, if it is not already defined. The specific nature of the search is implementation-defined.

All non-graphic characters are required to have names unless they have some implementation-defined attribute which is not null.

string might perform additional, implementation-defined conversions.

file n. a named entry in a file system, having an implementation-defined nature.

file compiler n. any compiler which compiles source code contained in a file, producing a compiled file as output. The compile-file function is the only interface to such a compiler provided by Common Lisp, but there might be other, implementation-defined mechanisms for invoking the file compiler.

[...] Otherwise, the parsing of thing is implementation-defined.

If thing contains an explicit host name and no explicit device name, then it is implementation-defined whether parse-namestring will supply the standard default device for that host as the device component of the resulting pathname.

This measure is in units of ems in order to be compatible with implementation-defined variable-width fonts while still not requiring the language to provide support for fonts.

(In the notes section, which is technically not normative...)

use---a list of package designators. The default is implementation-defined.

(!)

An implementation is free to support other (implementation-defined) declaration identifiers as well.

Each simple character must be representable in the readtable. It is implementation-defined whether non-simple characters can have syntax descriptions in the readtable.

Returns as an integer the current run time in internal time units. The precise meaning of this quantity is implementation-defined; it may measure real time, run time, CPU cycles, or some other quantity.

alphabetic n., adj. 1. adj. (of a character) being one of the standard characters A through Z or a through z, or being any implementation-defined character that has case, or being some other graphic character defined by the implementation to be alphabetic[1].

attribute n. (of a character) a program-visible aspect of the character. The only standardized attribute of a character is its code[2], but implementations are permitted to have additional implementation-defined attributes.

Whether or not the search is case-sensitive is implementation-defined.

lowercase adj. (of a character) being among standard characters corresponding to the small letters a through z, or being some other implementation-defined character that is defined by the implementation to be lowercase. See Section 13.1.4.3 (Characters With Case).

translate-logical-pathname might perform additional translations, typically to provide translation of file types to local naming conventions, to accomodate physical file systems with limited length names, or to deal with special character requirements such as translating hyphens to underscores or uppercase letters to lowercase. Any such additional translations are implementation-defined. Some implementations do no additional translations.

The next figure shows a list of all declaration identifiers defined by this standard. [...] An implementation is free to support other (implementation-defined) declaration identifiers as well.

em [...] In implementations providing non-Roman characters with wider characters than ``M,'' it is permissible for another character to be the implementation-defined reference character for this measure, and for ``M'' to be only a fraction of an em wide.

end of file n. 1. the point in an input stream beyond which there is no further data. Whether or not there is such a point on an interactive stream is implementation-defined.

external file format designator n. a designator for an external file format; that is, an object that denotes an external file format and that is one of: the symbol :default (denoting an implementation-dependent default external file format that can accomodate at least the base characters), some other object defined by the implementation to be an external file format designator (denoting an implementation-defined external file format), or some other object defined by the implementation to be an external file format (denoting itself).

pathname-match-p returns true if pathname matches wildcard, otherwise nil. The matching rules are implementation-defined but should be consistent with directory. Missing components of wildcard default to :wild.

All methods for print-object must obey *print-readably*. This includes both user-defined methods and implementation-defined methods.

The method specialized on class returns a creation form using the name of the class if the class has a proper name in environment, signaling an error of type error if it does not have a proper name. Evaluation of the creation form uses the name to find the class with that name, as if by calling find-class. If a class with that name has not been defined, then a class may be computed in an implementation-defined manner.

(??)

If a restart is invoked interactively by the debugger and does not transfer control but rather returns values, the precise action of the debugger on those values is implementation-defined.

An implementation is permitted to discard documentation strings at any time for implementation-defined reasons.

(!)