Clearing doc of a variable returns wrong value

Bug #1937354 reported by Olivier Certner
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

Execute the following:
> (defvar *test* nil "")
*TEST*
> (setf (documentation '*test* 'variable) nil)
T

The value returned by (SETF DOCUMENTATION) is T, but should be NIL.

This happens only for variables having documentation prior to the SETF. By contrast, clearing the documentation of a variable that does not have some, or of any function, works correctly.

Confirmed on 2.1.0 and development version 2.1.6.41-343f72115.

Fix attached.

Revision history for this message
Olivier Certner (olce) wrote :
Revision history for this message
Douglas Katzman (dougk) wrote :

the new-value argument has to be a string. If they meant "string or nil" then they would not have separately defined "documentation" and "new-value" in the "Arguments and Values"

(setf documentation) new-value x doc-type => new-value.

Arguments and Values:

x---an object.

doc-type---a symbol.

documentation---a string, or nil.

new-value---a string.

Revision history for this message
Olivier Certner (olce) wrote (last edit ):

You're right about what the standard mandates, I know it. It's just that restricting the NEW-VALUE to be only a string has drawbacks also:
1. There will be no clean external interface to remove specific documentation in a running image (sure, you could set it to "", but this is not something very satisfying). Or is there?
2. You'll lose "compatibility" with other CL environments. Including older versions of SBCL. CCL for example also allows NIL, with same semantics. ECL as well.

Are you sure you want to restrict the type of NEW-VALUE instead of this fix? If so, I can propose another patch.

Thanks.

Revision history for this message
Olivier Certner (olce) wrote :

In order to make progress quickly on this benign issue, I would suggest that you commit the fix as is and close the bug.

The issue of (SETF DOCUMENTATION) accepting NIL while the standard does not mention this specific possiblity, if too controversial, can be fixed into a separate bug. As argued above, this is a useful extension, and it is not prohibited by the standard (see CLHS 1.6 and (SETF DOCUMENTATION) (no explicit restrictions on extensions)).

Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers