ffi: support bitfields on types narrower than int.

* ffi.c (bit_s): New symbol variable.
(ffi_generic_sbit_put, ffi_generic_sbit_get,
ffi_generic_ubit_put, ffi_generic_ubit_get): New static
functions.
(bitfield_syntax_p): Include bit symbol in the check.
(make_ffi_type_pointer): Zero size is no longer an early
rejection test for bitfields; don't rely on it.
(make_ffi_type_struct): Revise the member calculating loop
to handle bitfields of various sizes. If a bitfield
follows one of a different size, it starts a new cell
even if the previous one has room, et cetera.
The masking and shifting is set up to work on cells of
int size; however, the new ffi_generic_s?bit_{put,get}
functions use a temporary buffer and transfer just the
right number of bytes to and from the actual buffer.
(ffi_struct_compile): The check against incomplete type
members only needs to test size zero; bitfields have nonzero
size now, which is the true size of the underlying storage
unit. They also have true alignment, which is used in
make_ffi_type_struct rather than hard-coding to alignof (int).
New syntax (bit width type) is now handled, where type can
be any of the signed and unsigned integral types up to int32
and int. The endian types are not supported for now.
(ffi_typedef, ffi_size, ffi_alignof): Zero size is no longer
an early rejection test for bitfields; don't rely on it.
(ffi_init): Initialize bit_s.

* ffi.h (bit_s): Declared.

* txr.1: Documented.

1 files changed, 87 insertions, 6 deletions

diff --git a/txr.1 b/txr.1
index 7ad8884c..ce42dfca 100644
--- a/txr.1
+++ b/txr.1
@@ -54164,9 +54164,10 @@ corresponding to the size of its type, plus any necessary additional padding
 for the alignment of the subsequent member.
 
 Structure members may be bitfields, which are described using the
-.code ubit
-and
+.codn ubit ,
 .code sbit
+and
+.code bit
 compound type operators.
 .meIP (array < dim << type )
 The FFI
@@ -54541,11 +54542,13 @@ The
 type denotes a bitfield of type
 .codn int .
 Unlike in the C language, it is not implementation-defined whether such
-a bit-field represents signed values; it converts between Lisp integers
+a bitfield represents signed values; it converts between Lisp integers
 that may be positive or negative, and a foreign representation which is
 two's complement.
 
-Bitfields of any other type are not supported.
+Bitfields based on some other types are supported using the more general
+.code bit
+operator, which is described below.
 
 The
 .meta width
@@ -54555,7 +54558,11 @@ zero to the number of bits in the
 .code uint
 type.
 
-In a structure, bitfields are allocated out in storage units which have the
+In a structure, bitfields produced by
+.code sbit
+and
+.code ubit
+are allocated out in storage units which have the
 same width and alignment requirements as a
 .codn uint .
 These storage units themselves can be regarded as anonymous members of the
@@ -54642,6 +54649,67 @@ A
 field of width 2 can represent the values -2, -1, 0 and 1, which are
 stored as the bit patterns 10, 11, 00 and 01, respectively.
 
+.meIP (bit < width << type )
+The
+.code bit
+operator is more general than
+.code ubit
+and
+.codn sbit .
+It allows for bitfields based on integer units smaller than or equal to 
+.codn uint .
+
+The
+.meta type
+argument may be any of the types
+.codn char ,
+.codn short ,
+.codn int ,
+.codn uchar ,
+.codn ushort ,
+.codn uint ,
+.codn int8 ,
+.codn int16 ,
+.codn int32 ,
+.codn uint8 ,
+.code uint16
+and 
+.codn uint32 .
+
+When the character types
+.code char
+and
+.code uchar
+are used as the basis of bitfields, they convert integer values, not
+characters.
+In the case of
+.codn char ,
+the bitfield is signed. 
+
+All remarks about
+.code ubit
+and
+.code sbit
+apply to
+.code bit
+also. The existence of
+.code bit
+creates the possibility that bitfields of different sizes may be
+placed adjacently within a structure. The rule is that whenever a non-zero-width
+bitfield follows another non-zero-width bitfield of a different storage
+unit size, a new storage unit begins for the new bitfield, even if the
+previous storage unit has room for the new bitfield. Bitfields occupying
+units of different sizes are never placed into the same unit.
+
+For this consideration, only size matters, not type or signedness. If two
+consecutive non-zero-width bitfields have storage unit types of the same
+size, they can be packed into the same storage unit.
+
+The alignment of the storage units follows that of type from which
+they are derived, unless overridden with the
+.code align
+operator.
+
 .meIP ({buf | buf-d} << size )
 The parametrized
 .code buf
@@ -54755,6 +54823,7 @@ It is possible to create a
 .code carray
 view over a buffer, using
 .codn carray-buf .
+
 .meIP (align < width << type )
 The FFI type operator
 .code align
@@ -54778,7 +54847,10 @@ the type as a structure member, and as an array element.
 A type with alignment 1 can be placed at any byte offset. A type with
 alignment 2 can be placed only at even addresses and offsets.
 
-Alignment can be applied to all types, including arrays and structs. However,
+Alignment can be applied to all types, including arrays and structs.
+It may also be applied to bitfields, but special considerations have
+to be observed to obtain the intended effect, described below.
+However,
 out of the elementary types, only the integer and floating point types are
 required to support a weakening of alignment. Whether a type which corresponds
 to a pointer, such as a
@@ -54800,6 +54872,15 @@ a member of an array or another structure, with its padding intact. To
 eliminate the padding at the end of a structure, it is necessary to use
 .code align
 to manipulate the alignment of individual members.
+
+When
+.code align
+is applied to the type of a bitfield member of a structure, it has no effect on
+placement, except when applied to the leading bitfield which begins a new
+storage unit.  The alignment of such a leading bitfield determines the
+alignment of that storage unit, and is taken into account for determining the
+most strictly aligned member of the structure. The alignment of all other
+bitfields is ignored.
 .PP
 
 The following additional typedef names are defined denoting some common