[Bug-openmcl] open :element-type
gb at clozure.com
Thu Jan 22 15:18:37 MST 2004
On Thu, 22 Jan 2004, bryan o'connor wrote:
> :element-type is unfairly restricted to ([un]signed-byte 32).
Who says it's unfair ?
> the standard says, "a type specifier for recognizable subtype of
> character; or a type specifier for a finite recognizable subtype
> of integer; or one of the symbols signed-byte, unsigned-byte, or
> :default. The default is character."
Oh, right. -That's- who says it's unfair.
> (open "tmp.dat" :direction :output
> :if-exists :supersede
> :element-type '(unsigned-byte 33))
> the restriction seems to be in make-heap-buffer. removing it
> does fix the problem.. but i imagine it's also creating some.
The dictionary entry for OPEN uses the term "reasonable" a couple
of times, noting that it's impossible for OPEN's behavior to be
fully specified in light of file-system differences.
It would probably be reasonable for a 32-bit implementation to error
on an element-type of (UNSIGNED-BYTE 1000000000000000) even though
that's a finite recognizable subtype of INTEGER.
Filesystems that this implementation runs on express position and
length in terms of 8-bit octets, so unless an integer element type is
upgraded to a multiple of 8 bits it's not always possible to reliably
append to a file, or to report or seek to a specified position, so
that kind of element-type upgrading seems reasonable. (Letting
these operations fail or return NIL might also be reasonable.)
It's probably not too hard to support element types that are multiples
of 8 bits up to some threshold. Currently, that threshold's 32. A
larger threshold might be nice (especially if anything but the test
suite had a need to deal in larger elements), but it's not clear to me
that the implementation -has- to support arbitrararily wide element
types or that a portable program can make too many assumptions about
what will be accepted without error.
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
More information about the Bug-openmcl