Lars Brinkhoff  <lars.spam@nocrew.org> wrote:
+---------------
| Kent M Pitman <pitman@world.std.com> writes:
| > (unsigned-byte 24) is not on the list of required [:element-type]
| > types that the implementation is required to support.
| 
| Is there such a list?  I couldn't find any when searching the HyperSpec.
+---------------

Hmmm... How about this [emphasis added]:

	<URL:http://www.lispworks.com/reference/HyperSpec/Body/f_open.htm>
	...
	element-type---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.

By following the glossary reference to "recognizable subtype" and
thence to SUBTYPEP, I interpreted that to mean that "(unsigned-byte 24)"
should be supported in in OPEN by some given implementation iff
(subtypep '(unsigned-byte 24) 'integer) => t, t in that implementation.

I say "should", because I couldn't get the following:

	(with-open-file (s "foo" :element-type '(unsigned-byte 4))
	  (loop for x = #1=(read-byte s nil nil) then #1#
		while x
		do (format t "~d~%" x)))

to work with either CMUCL or CLISP, even though both say that
(subtypep '(unsigned-byte 4) 'integer) => t, t

CMUCL treats (unsigned-byte 4) as (unsigned-byte 8), printing the
following for the above ["foo" contains "hello\n"]:

	104
	101
	108
	108
	111
	10
	NIL

And though '(unsigned-byte 16) works as expected, CMUCL unfortunately
treats '(unsigned-byte 24) as '(unsigned-byte 32):

	1819043176
	NIL

On the other hand, CLISP simply refuses to play at all when given
(unsigned-byte 4):

	*** - file #P"/u/rpw3/foo" is not an integer file
	1. Break [2]>

But it handles (unsigned-byte 24) just fine:

	7103848
	683884
	NIL

Go figure.


-Rob

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://www.rpw3.org/>
San Mateo, CA 94403		(650)572-2607