Hi all,

I noticed today that the SRFI leaves bitvector-segment's behavior
unspecified when its 'n' parameter is zero.  I think that this
should be an error; neither of the obvious alternatives
(return () or #f) make any sense to me.

SRFI 160 similarly leaves this unspecified.  Indeed, the sample
implementation for that SRFI runs forever when @vector-segment
is given a zero segment-length argument.

Since the SRFI 178 sample implementation of bitvector-segment
is a wrapper for u8vector-segment, it also goes off the rails.
I'll patch this to signal an error, if John agrees.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>