GNU bug report logs -
#6878
bool-vectors of length 0 signal error when aref/aset the 0th element
Previous Next
Reported by: MON KEY <monkey <at> sandpframing.com>
Date: Wed, 18 Aug 2010 04:19:02 UTC
Severity: minor
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
Full log
Message #76 received at 6878 <at> debbugs.gnu.org (full text, mbox):
On Wed, Aug 18, 2010 at 3:36 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> When aref/aset'ing the 0th element of a bool-vectors of length 0 i get
>> an args-out-of-range error:
>
> To have a 0th element, an array needs to be of length >= 1.
> So this behavior seems perfectly correct to me.
> An array of length N has elements 0..N-1, so an array of length
> 0 doesn't have any elements at all. This should be true of strings,
> vectors, and bool-vectors.
>
Note, a similar such issue was addressed by David Moon during the ANSI Common
Lisp standardization process.
:SEE ftp://ftp.parc.xerox.com/pub/cl/cleanup/old-mail/bit-array-functions.mail.Z
,----
| Date: Tue, 23 May 89 14:42 EDT
| From: David A. Moon <Moon <at> STONY-BROOK.SCRC.Symbolics.COM>
| Subject: Issue: BIT-ARRAY-FUNCTIONS (version 5)
|
| Proposal (BIT-ARRAY-FUNCTIONS:ADD):
|
| Allow the binary bit-array functions referenced above to accept
| arguments of identical rank but unequal dimensions. Nonexistent
| elements of bit-array-1 or bit-array-2 are assumed to be zero. If
| the third argument is T or a bit-array, result elements outside the
| bounds of the array must be zero or an error should be signalled.
| If the third argument is NIL or omitted, each dimension of the
| result array is equal to either the corresponding dimension of
| bit-array-1 or the corresponding dimension of bit-array-2. The
| larger of the two dimensions is used when necessary to hold all the
| nonzero elements of the result, otherwise either the larger or the
| smaller of the two dimensions is used.
|
`----
What is interestingly relevent to this bug report #6788 w/re
bool-vectsrs was Barry Margolin's initial response to Moon's
proposal above:
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar <at> Think.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
,----
|
| I'd like to suggest an additional change, which seems to be
| consistent with the attitude about use of bit vectors expressed in
| the proposal. The BIT and SBIT functions should return 0 if asked
| to access outside the bit array. This would maintain the tautology
|
| (bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
|
| If slowing down these functions (they'd be the only array accessors
| REQUIRED to check the dimensions) is considered unacceptable, then a
| new accessor should be added.
|
`----
Disregarding the fact that Emacs Lisp does not have anything
equivalent to the Common Lisp bit array functions it remains
noteworthy that a similar issue was considered during the Common Lisp
ratification and that a somewhat similar incontinuity was detected
with one aspect of a proposed solution being Margolin's suggestion that:
"The BIT and SBIT functions should return 0 if asked to access
outside the bit array."
Indeed, while I was not aware of Margolin's proposal at the time I
filed the current bug report his solution bears striking resemblance
to the one I provided with my initial bug report, namely:
,----
|
| Maybe something like this is needed:
|
| (defun safe-aref-bool-vector (bool-vector idx)
| (if (and (bool-vector-p bool-vector)
| (not (null (append bool-vector nil))))
| (aref bool-vector idx)
| 0))
|
| (defun safe-aset-bool-vector (bool-vector idx)
| (if (and (bool-vector-p bool-vector)
| (not (null (append bool-vector nil))))
| (aset bool-vector idx)
| 0))
|
`----
>
> Stefan
--
/s_P\
This bug report was last modified 14 years and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.