Possible bugs concerning bool-vectors.

Possible bugs concerning bool-vectors.

[Luc Teirlinck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

Is everything in the ielm run below actually OK or does it illustrate
bugs in the handling of bool-vectors?  It certainly illustrates
"features" that seem quite unintuitive.

===File ~/bool-ielm=========================================
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq b1 (make-bool-vector 3 t))
#&3"\a" ;; Of course, ^G is 7, definitely no bug here.
ELISP> (fillarray b1 t)
#&3"ÿ"  ;; this is the character with code 2303 
ELISP> (format "%o" 2303)
"4377" ;; the last 3 bits are still 7.  b1 has length 3.  OK.
ELISP> (setq b2 (make-bool-vector 3 t))
#&3"\a"
ELISP> (equal b1 b2)
nil  ;; this however looks strange to me.
ELISP> (setq b3 #&3"ÿ") ;; We set b3 to the printed representation of b1.
#&3"\a"
ELISP> (equal b1 b3)
nil  ;; b1 is not `equal' to the result of evaluating its
     ;; printed representation.
ELISP> (equal b2 b3)
t
ELISP> (length b1)
3    ;; Yes, b1 still has length 3.
ELISP> 
============================================================

Comments:

I can understand that fillarray winds up filling up an array used for
internal representation with length larger than 3, but b1 starts out
having length 3 and after the call to fillarray still has length 3.
Intuitively, it would seem that there are exactly 2^3 = 8 bool-vectors
of length 3, but apparently not, there are a huge number of them, due
to differences in additional internal spots.  Bug?

`fill-array' is supposed to work (give sensible and expected results)
for arbitrary arrays.  That includes bool-vectors.  Actually, the doc
string says so.  C-h f fillarray:

fillarray is a built-in function.
(fillarray ARRAY ITEM)

Store each element of ARRAY with ITEM.
ARRAY is a vector, string, char-table, or bool-vector.

My comments again:

Does anything in this doc string suggest the above behavior?

Sincerely,

Luc.

Re: Possible bugs concerning bool-vectors.

[Andreas Schwab]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Is everything in the ielm run below actually OK or does it illustrate
> bugs in the handling of bool-vectors?  It certainly illustrates
> "features" that seem quite unintuitive.
>
> ===File ~/bool-ielm=========================================
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (setq b1 (make-bool-vector 3 t))
> #&3"\a" ;; Of course, ^G is 7, definitely no bug here.
> ELISP> (fillarray b1 t)
> #&3"ÿ"  ;; this is the character with code 2303 

This should be fixed now.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Possible bugs concerning bool-vectors.

[Luc Teirlinck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Andreas Schwab wrote:

   > ===File ~/bool-ielm=========================================
   > *** Welcome to IELM ***  Type (describe-mode) for help.
   > ELISP> (setq b1 (make-bool-vector 3 t))
   > #&3"\a" ;; Of course, ^G is 7, definitely no bug here.
   > ELISP> (fillarray b1 t)
   > #&3"ÿ"  ;; this is the character with code 2303 

   This should be fixed now.

It is.  Thanks.

Sincerely,

Luc.