File: README.md

package info (click to toggle)
scheme-bytestructures 2.0.2-3
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 480 kB
  • sloc: lisp: 2,168; makefile: 73; sh: 8
file content (1157 lines) | stat: -rw-r--r-- 37,661 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
# Structured access to bytevector contents

## Example

```scheme
;; define a scheme bytestructure for a C struct
(define my-position-struct (bs:struct `((x ,int) (y ,int))))

;; initialize an instance of `my-position-struct`
(define position (bytestructure my-position-struct))

;; bytestructure-set!
(bytestructure-set! position 'x 42)
(bytestructure-set! position 'y 101)

;; bytestructure-ref
(bytestructure-ref position 'x) ;; => 42

;; retrieve the underlying bytevector
(define bv (bytestructure-bytevector position)) ;; => #vu8(42 0 0 0 101 0 0 0)

;; creating a bytestructure from an existing bytevector
(define position2 (make-bytestructure bv 0 my-position-struct))
```

There is also a faster macro API.

## Introduction

This library offers a system imitating the type system of the C
programming language, to be used on bytevectors.  C's type system
works on raw memory, and ours works on bytevectors which are an
abstraction over raw memory in Scheme.  The system is in fact more
powerful than the C type system, elevating types to first-class
status.

A C type corresponds to a "bytestructure descriptor" object in our
system.

```scheme
;; typedef uint8_t uint8_v3_t[3];
(define uint8-v3 (bs:vector 3 uint8))

;; typedef struct { uint16_t x; uint8_v3_t y; } my_struct_t;
(define my-struct (bs:struct `((x ,uint16) (y ,uint8-v3))))
```

These can then be bundled with a bytevector, yielding a
"bytestructure" object on which referencing and assignment work in
accordance with the types declared in the descriptor.

```scheme
;; my_struct_t str;
(define str (bytestructure my-struct))

;; my_struct_t str = { 0, 1 };
(define str (bytestructure my-struct #(0 1)))

;; str.y[2]
(bytestructure-ref str 'y 2)

;; str.y[2] = 42;
(bytestructure-set! str 'y 2 42)
```

If your Scheme implementation supports syntax-case, then a macro-based
API is available as well, for when the procedural API is too slow for
your purposes.

```scheme
(define-bytestructure-accessors my-struct
   my-struct-unwrap my-struct-ref my-struct-set!)

(define foo (make-bytevector ...))

;; foo.y[2]
(my-struct-ref foo y 2)

;; foo.y[2] = 42;
(my-struct-set! foo y 2 42)
```

(Note that we don't use the bytestructure data type anymore; we work
directly on bytevectors.  The struct fields are also implicitly quoted
and can't be variable references, since their look-up will happen at
compile time.  The unwrapper will be explained later.)

There are also "dynamic" bytestructure descriptors, whose behavior
depends on the bytevector on which they're used.  For instance a
binary file format may specify that there are tag bytes declaring the
lengths of following fields.  The system can express this cleanly.


## Supported platforms

R7RS and GNU Guile are supported.  Detailed instructions per Scheme
implementation follow.

### Chibi

- Clone the Larceny source repository:

  ```
  git clone https://github.com/larcenists/larceny
  ```

- Append `$larceny_repo/tools/R6RS` to the Chibi load-path via the
  `-A` command-line flag.

- Append this directory to the Chibi load-path via the `-A`
  command-line flag.

- Import `(bytestructures r7)`.

### Gauche

- Clone the Larceny source repository:

  ```
  git clone https://github.com/larcenists/larceny
  ```

- Go to its `tools/R6RS/r6rs/` sub-directory.

- Run the following shell command in that directory and its
  sub-directories:

  ```bash
  for file in *.sld; do
     name=${file%.sld}
     ln -s $file $name.scm
  done
  ```

- Add `$larceny_repo/tools/R6RS` to `GAUCHE_LOAD_PATH`.

- Add this directory to `GAUCHE_LOAD_PATH`.

- Import `(bytestructures r7)`.

### Guile

- Add this directory to `GUILE_LOAD_PATH`.

(You can use the `-L` command line flag instead of augmenting
`GUILE_LOAD_PATH`, but don't use it with a relative path, because
`include-from-path` doesn't work well with that, which we use.)

- Import `(bytestructures guile)`.

### Kawa

- Clone the Larceny source repository:

  ```
  git clone  https://github.com/larcenists/larceny
  ```

- Run Kawa with a command line flag such as the following to add
  `$larceny_repo/tools/R6RS` and this directory to the load path, and
  to make it look for `.sld` files:

  ```
  -Dkawa.import.path="$bytestructures_repo/*.sld:$larceny_repo/tools/R6RS/*.sld"
  ```

(The `*` stands for any number of directories, so sub-directories will
also be searched for `.sld` files.)

- Import `(bytestructures r7)`.

### Larceny

- Add this directory to `LARCENY_LIBPATH`.

- Run Larceny with the `-r7rs` flag.

- Import `(bytestructures r7)`.


## Specification

A *bytestructure descriptor*, also called simply a descriptor within
this specification, is an object encapsulating information about the
layout and meanings of the bytes in a bytevector object.

A *bytestructure* is an object bundling a bytevector with a
bytestructure descriptor so that values can be extracted from that
bytevector conveniently, using the information in the descriptor.

A *dynamic descriptor* is a bytestructure descriptor whose `size`
and/or `unwrapper` procedures reference their `bytevector` and/or
`offset` arguments.  (See below.)

The argument name `descriptor` signifies that an argument must be a
bytestructure descriptor, `bytestructure` signifies that it must be a
bytestructure, and `offset` signifies that it must be an exact
non-negative integer.

Knowledge of the C programming language is recommended for a proper
understanding of this specification.  Specifically, example code is
often annotated with conceptually equivalent C code.


### High-level API

A set of predefined bytestructure descriptors, as well as procedures
for creating compound descriptors of certain kinds, are provided to
the user, mostly obviating the need to work with the bytestructure
descriptor API directly, which is explained further below.


#### Constructors for compound descriptors

##### bs:vector

- `(bs:vector length descriptor)` *procedure*

Returns a descriptor for vectors, also called a *vector descriptor*,
of length `length` and the *element descriptor* `descriptor`.  This
corresponds to an *array type* in the C programming language.

```scheme
;; uint16_t vec[3] = { 0, 1, 2 };
(define vec (bytestructure (bs:vector 3 uint16) #(0 1 2)))

;; vec[1]
(bytestructure-ref vec 1)

;; vec[1] = 42;
(bytestructure-set! vec 1 42)
```

The elements are indexed with exact non-negative integers, and no
bounds checking is done; an off-bounds index will either raise an
error due to an off-bounds bytevector index, or attempt to decode
whatever bytes are found at the relevant place in the bytevector,
which might result in a valid value without raising an error.

Vector descriptors are normally meant for indexing through, but also
allow direct assignment.  The value provided for assignment must be a
regular Scheme vector of the same length as the vector descriptor.
Each element of that vector is assigned to the corresponding element
of the vector bytestructure, using the assignment semantics of the
element descriptor.

```scheme
;; (Reusing 'vec' from the previous example.)

;; Uses bytevector-u16-set! three times.
(bytestructure-set! vec #(21 42 84))
```

One may also provide a bytevector, in which case as many bytes as
the size of the bytestructure will be copied into it.

```scheme
;; The results of this depend on endianness.
;; Only the first 6 bytes from the bytevector will be copied.
(bytestructure-set! vec #u8(0 1 2 3 4 5 6 7 8))
```

These assignment semantics may not be used with the macro API.

Vector descriptors don't accept dynamic descriptors as their element
descriptor, because they calculate their total size eagerly and thus
need to know the size of their element descriptor independently from
the bytevector on which they will be used.

##### bs:struct

- `(bs:struct fields)` *procedure*
- `(bs:struct pack fields)` *procedure*

Returns a descriptor for structs, also called a *struct descriptor*.
`Fields` must be a list of *field specs* (see below).  `Pack` may be
`#f`, `#t`, or an exact positive integer.  If `pack` is omitted or
`#f`, the struct alignment of the platform's C ABI is used.  If `pack`
is `#t`, there are no padding fields (except for those resulting from
bit-fields).  If `pack` is an integer, it specifies the maximum
alignment value for the fields, similar to the `#pack` directive of
the GCC C compiler.

A *field spec* is a list of two or three elements.  The first element
must be a symbol which names the field (or `#f`, see below).  Every
field must have a distinct name (except if `#f`).  The second element
must be a bytestructure descriptor which becomes the descriptor of the
field.  The third element, if present, must be an exact non-negative
integer; it signifies that the field is a bit-field of that width.
The descriptor of a bit-field must be one that decodes values to exact
integers, such as for instance `uint8` or `int32`.

Alternatively, a field spec may be of the form `(union *fields*)`
where *fields* is again a list of field specs.  This feature
corresponds to *anonymous unions* in the C11 standard.

The width of a bit-field may be zero, which means padding should be
inserted in its place until the next alignment boundary of the
descriptor of that bit-field is reached.  A zero-width bit-field must
have `#f` as its name.

```scheme
;; typedef struct { uint8_t x; uint16_t y; } my_struct_t;
(define my-struct (bs:struct `((x ,uint8) (y ,uint16))))

;; my_struct_t str = { 0, 1 };
(define str (bytestructure my-struct #(0 1)))

;; my_struct_t str = { .y = 1, .x = 0 };
(define str (bytestructure my-struct '((y 1) (x 0))))

;; str.y
(bytestructure-ref str 'y)

;; str.y = 42;
(bytestructure-set! str 'y 42)

;; Assuming a 32-bit platform:

;; struct { unsigned int a:16; unsigned int b:16; }
(bs:struct `((a ,uint32 16) (b ,uint32 16)))

;; struct { unsigned int a:16; int :0; signed int b:20; }
(bs:struct `((a ,uint32 16) (#f ,int32 0) (b ,int32 20)))
```

Struct descriptors are normally meant for indexing through, but also
allow direct assignment.  The value provided for assignment may be a
Scheme vector as long as there are fields in the struct descriptor,
which will assign all fields sequentially; or a list of two-element
lists, which will assign any number of fields by name.

```scheme
;; (Reusing 'str' from the previous example.)

;; str = (my_struct_t){ 0, 1 };
(bytestructure-set! str #(0 1))

;; str = (my_struct_t){ .y = 2, .x = 1 };
(bytestructure-set! str '((y 2) (x 1)))
```
One may also provide a bytevector, in which case as many bytes as
the size of the bytestructure will be copied into it.

```scheme
;; The field 'x' is set to 0; the value of the field 'y' will
;; depend on endianness.
;; Only the first 3 bytes from the bytevector will be copied.
(bytestructure-set! str #u8(0 1 2 3 4 5))
```

These assignment semantics may not be used with the macro API.

Struct descriptors don't accept dynamic descriptors as field
descriptors, because they calculate their total size eagerly.

When using the macro API, the field names are implicitly quoted and
looked up at macro-expand time.

```scheme
(define-bytestructure-accessors my-struct
  my-struct-unwrap my-struct-ref my-struct-set!)

;; foo.y
(my-struct-ref foo-bytevector y)

;; foo.y = 42;
(my-struct-set! foo-bytevector y 42)
```

##### bs:union

- `(bs:union fields)` *procedure*

Returns a descriptor for unions, also called a *union descriptor*.
`Fields` has the same format as in `bs:struct`.

```
;; typedef union { uint8_t x; uint16_t y; } my_union_t;
(define my-union (bs:union `((x ,uint8) (y ,uint16))))

;; my_union_t union = { .y = 42 };
(define union (bytestructure my-union '(y 42)))

;; union.y
(bytestructure-ref union 'y)

;; union.y = 42;
(bytestructure-set! union 'y 42)
```

Union descriptors are normally meant for indexing through, but also
allow direct assignment.  The value provided for assignment must be a
two-element list, whose first element names the field whose descriptor
should be used for the assignment, and the second element provides the
value to be actually assigned.

```scheme
;; union.y = 42;
(bytestructure-set! union '(y 42))
```

*Rationale:* This syntax isn't shorter than the normal way of
assigning a value into the union, but is supported for reasons that
should become apparent after reading the specification of the
`bytestructure` constructor procedure.

One may also provide a bytevector, in which case as many bytes as
the size of the bytestructure will be copied into it.

```
;; The value of the y field will depend on endianness.
;; Only the first 2 bytes from the bytevector will be copied.
(bytestructure-set! union #u8(0 1 2 3 4))
```

These assignment semantics may not be used with the macro API.

Union descriptors don't accept dynamic descriptors as field
descriptors, because they calculate their total size eagerly.

##### bs:pointer

- `(bs:pointer descriptor)` *procedure*

Returns a descriptor for pointers, also called a *pointer descriptor*,
with the *content descriptor* `descriptor`.  Such a descriptor
indicates that the bytes in a given bytevector are to be interpreted
as a memory address.  The content descriptor is the descriptor for the
bytes found at that memory address.

```scheme
;; foo_struct *ptr = 0x12345678;
(define ptr (bytestructure (bs:pointer foo-struct) #x12345678))
```

For void pointers, the symbol `void` may be used in place of a content
descriptor:

```scheme
;; void *ptr;
(define ptr (bytestructure (bs:pointer 'void)))
```

As a special case, the `descriptor` argument to `bs:pointer` may be a
promise, which must evaluate to a descriptor when forced.  This is to
allow creating self-referencing descriptors:

```scheme
;; typedef struct linked_uint8_list_s {
;;   uint8_t head;
;;   struct linked_uint8_list_s *tail;
;; } *linked_uint8_list_t;
(define linked-uint8-list
  (bs:pointer (delay (bs:struct `((head ,uint8)
                                  (tail ,linked-uint8-list))))))
```

The symbol `*` can be used as an index to dereference the pointer.
(It's implicitly quoted when used in the macro API.)  An array of
bytes as large as the size of the content descriptor, starting from
the memory address of the pointer, are reified into a bytevector
object, and bundled with the content descriptor, to yield a new
bytestructure object.

```scheme
;; linked_uint8_list_t u8list;
(define u8list (bytestructure linked-uint8-list))

;; u8list->head
(bytestructure-ref u8list '* 'head)

;; u8list->head = 42;
(bytestructure-set! u8list '* 'head 42)
```

One may also provide an integer index, which will result in an offset
being applied while creating the reified bytevector:

```scheme
;; uint8_t *u8array;
(define u8array (bytestructure (bs:pointer uint8)))

;; u8array[5]
(bytestructure-ref u8array 5)

;; u8array[5] = 42
(bytestructure-set! u8array 5 42)
```

*Note:* Since dereferencing a pointer involves the creation of a new
bytevector object, it's a rather inefficient operation relative to
what it achieves (following a pointer).  As such, you might want to
minimize the use of pointer dereferences in performance-critical
sections of code.  Note that using the macro API does *not* work
around this issue, as the bytevector still needs to be created at
run-time to access the data referenced by the pointer.  To minimize
the number of bytevector allocations, create one explicitly with the
appropriate size.  Example with Guile:

```scheme
(import (bytestructures guile))
(import (rnrs bytevectors))
(import (prefix (system foreign) ffi:))

;; struct string { size_t len; char *chars; }
(define string-descriptor
  (bs:struct `((len ,size_t) (chars ,(bs:pointer uint8)))))

;; struct string my_string;
(define my-string (bytestructure string-descriptor))

;; my_string.len = 30;
(bytestructure-set! my-string 'len 30)

;; my_string.chars = malloc(30);
(bytestructure-set! my-string 'chars (make-bytevector 30))

;; Let's hope the bytevector doesn't get garbage collected!

;; Slow code to take the sum of all chars:
(let ((len (bytestructure-ref my-string 'len)))
  (do ((i 0 (+ i 1))
       (sum 0 (+ sum (bytestructure-ref my-string 'chars i))))
      ((= i len) sum)))

;; Fast code:
(let* ((len (bytestructure-ref my-string 'len))
       (addr (bytestructure-ref my-string 'chars))
       (pointer (ffi:make-pointer addr))
       (bv (ffi:pointer->bytevector pointer len)))
  (do ((i 0 (+ i 1))
       (sum 0 (+ sum (bytevector-u8-ref bv i))))
      ((= i len) sum)))

;; Or continue with bytestructures after following the pointer:
(let* ((len (bytestructure-ref my-string 'len))
       (addr (bytestructure-ref my-string 'chars))
       (pointer (ffi:make-pointer addr))
       (bv (ffi:pointer->bytevector pointer len))
       (chars (make-bytestructure bv 0 (bs:vector len uint8))))
  (do ((i 0 (+ i 1))
       (sum 0 (+ sum (bytestructure-ref chars i))))
      ((= i len) sum)))
```

Since pointers are also values themselves, pointer descriptors also
have direct referencing and assignment semantics.  Referencing the
pointer yields the numeric value of the address.

```scheme
;; linked_uint8_list_t u8lists[3];
(define u8lists (bytestructure (bs:vector 3 linked-uint8-list)))

;; Returns the address stored in u8lists[1].
(bytestructure-ref u8lists 1)
```

Assignment with a pointer descriptor allows a variety of values.
Firstly, a numeric value (taken to be a memory address) may be given,
which causes that value itself to be written.

```scheme
;; uint8_t (*u8v3-ptr)[3];
(define u8v3-ptr (bytestructure (bs:pointer (bs:vector 3 uint8))))

;; u8v3-ptr = 0xdeadbeef;
(bytestructure-set! u8v3-ptr #xdeadbeef)
```

A bytevector may be given, in which case the memory address of the
first byte of the bytevector is written.

```scheme
;; Makes the pointer point to 'a-bytevector'.
(bytestructure-set! u8v3-ptr a-bytevector)
```

Lastly, providing a bytestructure is equivalent to providing the
bytevector of that bytestructure.

```scheme
;; Makes the pointer point to the bytevector of 'a-bytestructure'.
(bytestructure-set! u8v3-ptr a-bytestructure)
```

These assignment semantics may be used with the macro API as well.

Pointers don't accept dynamic descriptors as their content descriptor.

*Rationale:* The bytevector that is pointed to is reified "on the fly"
during referencing operations, for which its size needs to be known in
advance.  Needing the bytevector to already exist for calculating its
size (as is the case for dynamic descriptors) imposes a problem of
circularity.

*Note:* Having an address written into a bytevector may not protect it
from garbage collection.  Thus using pointer descriptors might make a
Scheme program memory unsafe even if the Scheme implementation is
otherwise memory safe.


#### Numeric descriptors

The following descriptors for numeric types are provided:
`[u]int(8,16,32,64)[le,be]`, `float(32,64)[le,be]`,
`complex(64,128)[le,be]`

On platforms with little-endian byte order, the descriptors whose name
ends in `le` are equivalent as per `eqv?` to their variant without an
explicit endianness marker.  The same applies for the big-endian
descriptors on big-endian platforms.

The following are each equivalent as per `eqv?` to one of the above
listed descriptors, depending on the platform on which the Scheme
program is run: `[unsigned-](short,int,long,long-long)`,
`[u]intptr_t`, `[s]size_t`, `ptrdiff_t`, `float`, `double`

These descriptors cannot be indexed through as for instance vectors
and structs can; they can only be used to directly reference or assign
values.

```scheme
;; uint32_t x;
(define x (bytestructure uint32))

;; x = 42;
(bytestructure-set! x 42)

;; uint32_t xs[3];
(define xs (bytestructure (bs:vector 3 uint32)))

;; xs[1] = 42;
(bytestructure-set! xs 1 42)
```


#### String descriptors

- `(bs:string size encoding)` *procedure*

Returns a descriptor for a string occupying `size` bytes, encoded in
`encoding` (a symbol).  Currently supported encodings:

- `ascii`
- `utf8`
- `utf16le`
- `utf16be`
- `utf32le`
- `utf32be`

If the ASCII encoding is specified, an error is raised if a non-ASCII
character is encountered during encoding or decoding.

Byte-order marks are not supported (yet).

```scheme
(define x (bytestructure (bs:string 8 'utf16le)))

(bytestructure-set! x "1234")

(bytestructure-ref x)  ;=> "1234"
```

When writing a string into a bytevector via such a descriptor, the
given string must fit into the given size after encoding, otherwise an
error is raised.  If the string is shorter than the size, the
remaining bytes of the bytevector are zeroed if the specified encoding
is variable-width (UTF-8 and UTF-16), otherwise an error is raised.

```scheme
(define x (bytestructure (bs:string 4 'utf8)))

(bytestructure-set! x "12345")  ;error

(bytestructure-set! x "123")
(bytestructure-ref x)  ;=> "123\x00"
```


#### Null-terminated C strings

*Currently only supported on Guile.*

The `cstring-pointer` descriptor can be used to represent a pointer to
a null-terminated string.  A reference operation will return that
string as a Scheme string.  The setter only takes addresses to
existing C strings however, due to the difficulty of holding a
reference to the associated pointer object in Scheme.

```scheme
(import (prefix (system foreign) ffi:))  ;use Guile FFI module

(define bs (bytestructure cstring-pointer))

;; This creates a null-terminated string "foobar\0" in memory, giving
;; us a pointer object holding its address.
(define ptr (ffi:string->pointer "foobar"))

;; Write the address of "foobar\0" into the backing bytevector.
(bytestructure-set! bs (ffi:pointer-address ptr))

;; Get the null-terminated string whose address is found in the
;; backing bytevector.
(bytestructure-ref bs)  ;=> "foobar"
```


#### The bytestructure data type

- `(make-bytestructure bytevector offset descriptor)` *procedure*

Returns a bytestructure object with the given bytevector, offset into
the bytevector, and bytestructure descriptor.

*Rationale:* Any bytestructure descriptor can be used with any
bytevector to work on it momentarily in accordance with the
descriptor, but in most cases a bytevector is dedicated to a certain
structure, so it makes sense to bundle a descriptor with the
bytevector.  Or only a portion of the bytevector, starting from a
certain offset, might be dedicated to the structure, so being able to
bundle that offset is also useful.

- `(bytestructure? obj)` *procedure*

Returns a Boolean indicating whether `obj` is a bytestructure.

- `(bytestructure-bytevector bytestructure)` *procedure*
- `(bytestructure-offset bytestructure)` *procedure*
- `(bytestructure-descriptor bytestructure)` *procedure*

These procedures return the `bytevector`, `offset`, and `descriptor`
values respectively, with which `bytestructure` was created.

- `(bytestructure-size bytestructure)` *procedure*

Returns the size of the structure contained within `bytestructure`.

- `(bytestructure descriptor)` *procedure*
- `(bytestructure descriptor initial-value)` *procedure*

Creates a bytestructure with a newly allocated bytevector of the right
size for `descriptor` and an offset of 0, and optionally initializes
it with values.

The following two expressions are equivalent:

```scheme
(define bs (bytestructure descriptor))
```

```scheme
(define bs (make-bytestructure
            (make-bytevector (bytestructure-descriptor-size
                              descriptor))
            0
            descriptor))
```

The optional second argument is passed to `bytestructure-set!` to
assign the given values to the bytestructure after creation, meaning
the following two expressions are equivalent:

```scheme
(define bs (bytestructure descriptor values))

(let ((bs (bytestructure descriptor)))
  (bytestructure-set! bs values)
  bs)
```

Since the setter procedures of compound descriptors tend to delegate
the assignment of individual elements to their respective descriptors,
one can easily initialize structures to arbitrary depth.

```scheme
(define my-struct
  (bs:struct `((x ,uint16) (y ,(bs:vector 3 uint8)))))

(define bs (bytestructure my-struct '((x 0) (y #(0 1 2)))))
```


#### Referencing and assignment

- `(bytestructure-ref bytestructure index ...)` *syntax*

Traverses through `bytestructure` using `bytestructure-unwrap` with
the given indices to acquire a triple of a bytevector, offset, and
descriptor.  Then, applies the `getter` of that descriptor to the
bytevector and offset.  Or if the getter is `#f`, then a bytestructure
encapsulating that bytevector, offset, and descriptor is returned.

Note that this means that calling `bytestructure-ref` with zero index
arguments will return a bytestructure identical to the one provided.

- `(bytestructure-set! bytestructure index ... value)` *syntax*

Traverses through `bytestructure` using `bytestructure-unwrap` with
the given indices to acquire a triple of a bytevector, offset, and
descriptor.  Then, applies the `setter` of that descriptor to the
bytevector, offset, and `value`.  Or if the setter is `#f`, then
`value` must be a bytevector; as many bytes as the size of the
descriptor are copied from it into the bytevector, starting from the
offset.

- `(bytestructure-ref* bytevector offset descriptor index ...)`
  *syntax*
- `(bytestructure-set!* bytevector offset descriptor index ... value)`
  *syntax*

These macros have the same semantics as `bytestructure-ref` and
`bytestructure-set!` respectively, except that they start the
referencing process with the given `bytevector`, `offset`, and
`descriptor`, instead of the bytevector, offset, and descriptor of a
given bytestructure.

- `(bytestructure-unwrap bytestructure index ...)` *syntax*

This macro executes the following algorithm:

1. Extract the bytevector, offset, and descriptor of `bytestructure`.
   Let us call the triple of these values the *working set*.

2. If no indices are left, return the working set as three values.

3. Apply the `unwrapper` procedure of the descriptor to the
   bytevector, the offset, and the first index.  The return values
   replace the working set.  Pop the index from the list of indices.

4. Go to step 2.

*Note:* `bytestructure-unwrap` can be used with zero indices to
destructure a bytestructure into its contents.

```scheme
(let-values (((bytevector offset descriptor)
              (bytestructure-unwrap bytestructure)))
  ...)
```

- `(bytestructure-unwrap* bytevector offset descriptor index ...)`
  *syntax*

This macro has the same semantics as `bytestructure-unwrap`, except
that it starts the traversal process with the given `bytevector`,
`offset`, and `descriptor`, instead of the bytevector, offset, and
descriptor of a given bytestructure.

When a descriptor is not a dynamic descriptor, `bytestructure-unwrap*`
may be given a bogus `bytevector` argument.

```scheme
(bytestructure-unwrap* #f 0 uint8-v3-v5 2)
=> #f, 6, uint8-v3 ;; Two uint8-v3s were skipped, so offset 6.

(bytestructure-unwrap* #f 0 uint8-v3-v5 2 1)
=> #f, 7, uint8 ;; Two uint8-v3s and one uint8 was skipped.
```

- `(bytestructure-ref/dynamic bytestructure index ...)` *procedure*
- `(bytestructure-set!/dynamic bytestructure index ... value)`
  *procedure*

These procedures are equivalent to the macros `bytestructure-ref` and
`bytestructure-set!` respectively.

*Rationale:* Since these procedures take a variable number of
arguments, they have to allocate rest-arguments lists, which might be
undesirable in the general case.


#### Macro-based API

For when maximal efficiency is desired, a macro-based API is offered,
so that the bulk of the work involved in offset calculation can be
offloaded to the macro-expand phase.

- `(define-bytestructure-accessors descriptor unwrapper getter
  setter getter* setter*)` *syntax*

The `descriptor` expression is evaluated during the macro-expand phase
to yield a bytestructure descriptor.  The `unwrapper`, `getter`, and
`setter` identifiers are bound to a triple of macros implementing the
indexing, referencing, and assignment semantics of the descriptor.
The `getter*` and `setter*` variants allow an initial offset argument,
whereas the plain variants implicitly use 0 as the base offset.

```scheme
(define-bytestructure-accessors (bs:vector 5 (bs:vector 3 uint8))
  uint8-v3-v5-unwrap
  uint8-v3-v5-ref
  uint8-v3-v5-set!
  uint8-v3-v5-ref*
  uint8-v3-v5-set!*)

(uint8-v3-v5-unwrap #f 0 3 2)  ;the #f is a bogus bytevector
                               ;the 0 is the initial offset
=> 11 (3 * 3 + 2)

;; bv = uint8_t[15]{ 0, 1, 2, ... 14 };
(define bv (apply bytevector (iota 15)))

;; ((uint8_t[5][3]) bv)[2][1]
(uint8-v3-v5-ref bv 2 1) => 7

;; ((uint8_t[5][3]) bv)[2][1] = 42
(uint8-v3-v5-set! bv 2 1 42)

;; ((uint8_t[5][3]) bv)[2][1]
(uint8-v3-v5-ref bv 2 1) => 42

;; bv2 = uint8_t[20]{ 0, 1, 2, ... 19 };
(define bv2 (apply bytevector (iota 20)))

;; ((uint8_t[5][3]) (bv2 + 5))[2][1]
(uint8-v3-v5-ref* bv2 5 2 1) => 12

;; ((uint8_t[5][3]) (bv2 + 5))[2][1] = 42
(uint8-v3-v5-set!* bv2 5 2 1 42)

;; ((uint8_t[5][3]) (bv2 + 5))[2][1]
(uint8-v3-v5-ref* bv2 5 2 1) => 42
```

The macro API internally uses the following procedures during the
macro-expand phase to generate the desired output syntax:

- `(bytestructure-unwrap/syntax bytevector-syntax offset-syntax
  descriptor indices-syntax)` *procedure*

The semantics are akin to `bytestructure-unwrap*`, except that some
arguments are syntax objects, and the return value is a syntax object
that would evaluate to two values: the bytevector and offset that are
the result of the indexing process.

- `(bytestructure-ref/syntax bytevector-syntax offset-syntax
  descriptor indices-syntax)` *procedure*

The semantics are akin to `bytestructure-ref*`, except that some
arguments are syntax objects, and the return value is a syntax object
that would evaluate to the decoded value.

- `(bytestructure-set!/syntax bytevector offset descriptor indices
  value)` *procedure*

The semantics are akin to `bytestructure-set!*`, except that some
arguments are syntax objects, and a syntax object is returned that
would perform the actual assignment when evaluated.


### The bytestructure descriptors API

- `(make-bytestructure-descriptor size alignment unwrapper getter
  setter)` *procedure*

`Size` must be an exact non-negative integer, or a procedure taking
three arguments and returning an exact non-negative integer (this is
for dynamic descriptors).  The first argument to the procedure is a
Boolean indicating whether the call to the procedure is happening in
the macro-expand phase.  If it's false, the other two arguments are a
bytevector and an offset into the bytevector respectively.  If it's
true, then the two arguments are instead syntax objects that would
evaluate to a bytevector and an offset respectively.  The offset is
the position in the bytevector at which the bytes belonging to the
descriptor start.  The procedure should return the size of the
structure described by the descriptor, or return a syntax object that
would evaluate to the size.

`Alignment` must be an exact positive integer specifying the type's
preferred memory alignment.

`Unwrapper` must be `#f` or a procedure taking four arguments: a
Boolean indicating whether the call to the procedure is happening in
the macro-expand phase, a bytevector (or syntax object thereof), an
offset (or syntax object thereof), and an index object (or syntax
object thereof).  The procedure must return three values: the same or
another bytevector (or syntax object thereof), a new offset (or syntax
object thereof), and a bytestructure descriptor (NOT a syntax object
thereof).  This procedure implements the indexing semantics of
compound types.  The bytevector argument is provided to satisfy
dynamic descriptors; the `unwrapper` of non-dynamic descriptors should
ignore its value and return it back untouched.

`Getter` must be `#f` or a procedure taking three arguments: a Boolean
indicating whether the call to the procedure is happening in the
macro-expand phase, a bytevector (or syntax object thereof), and an
offset (or syntax object thereof).  The procedure should decode the
bytes at the given offset in the given bytevector (or return a syntax
object whose evaluation would do this), thus implementing the
referencing semantics of the descriptor.

`Setter` must be `#f` or a procedure taking four arguments: a Boolean
indicating whether the call to the procedure is happening in the
macro-expand phase, a bytevector (or syntax object thereof), an offset
(or syntax object thereof), and a value (or syntax object thereof).
The procedure should encode the given value into given offset in the
given bytevector (or return a syntax object whose evaluation would do
this), thus implementing the assignment semantics of the descriptor.

- `(bytestructure-descriptor-size descriptor)` *procedure*
- `(bytestructure-descriptor-size descriptor bytevector offset)`
  *procedure*

Returns the size of `descriptor`.  If `descriptor` is a dynamic
descriptor, then the `bytevector` and `offset` arguments must be
provided, which will be passed to the `size` procedure of
`descriptor`, with the macro-expand Boolean argument set to false.

```scheme
(bytestructure-descriptor-size uint8-v3-v5)
=> 15, because 3×5 8-bit integers in total.

(bytestructure-descriptor-size a-dynamic-descriptor)
;;; error

(bytestructure-descriptor-size
 a-dynamic-descriptor bytevector offset)
=> 42
```

- `(bytestructure-descriptor-size/syntax descriptor)` *procedure*
- `(bytestructure-descriptor-size/syntax descriptor bytevector-syntax
  offset-syntax)` *procedure*

Returns a syntax object that would evaluate to the size of
`descriptor`.  If `descriptor` is a dynamic descriptor, then the
`bytevector-syntax` and `offset-syntax` arguments must be provided,
which will be passed to the `size` procedure of `descriptor`, with the
macro-expand Boolean argument set to true.

- `(bytestructure-descriptor-alignment descriptor)` *procedure*
- `(bytestructure-descriptor-unwrapper descriptor)` *procedure*
- `(bytestructure-descriptor-getter descriptor)` *procedure*
- `(bytestructure-descriptor-setter descriptor)` *procedure*

These procedures return the `alignment`, `unwrapper`, `getter`, and
`setter` values respectively, with which `descriptor` was created.


## Performance

### Macro API

The macro API incurs zero run-time overhead for normal referencing and
assignment operations, since most things happen in the macro-expand
phase.

Plain bytevector reference:

```scheme
> (define times (iota 1000000)) ;A million
> (define bv (make-bytevector 1))
> (define (ref x) (bytevector-u8-ref bv 0))
> ,time (for-each ref times)
;; ~0.14s real time
```
Bytestructure reference:

```scheme
> (define bv (make-bytevector 1000))
> (define-bytestructure-accessors
    (bs:vector 5 (bs:vector 5 (bs:struct `((x ,uint8)
                                           (y ,uint8)
                                           (z ,uint8)))))
    bs-unwrap bs-ref bs-set!)
> (define (ref x) (bs-ref bv 4 4 z))
> ,time (for-each ref times)
;; ~0.14s real time
```

(Ignoring the jitter for both.)


### Procedural API

When descriptors are statically apparent, an aggressively constant
propagating and partial evaluating optimizer might be able to turn
bytestructure references into direct bytevector references, yielding
identical results to the macro API.  That is the most optimal outcome,
but more realistic is that most of the work happens at run-time.

The offset calculation avoids allocation, which will make its speed
predictable.  It takes linear time with regard to the depth of a
structure.  For structs and unions, it's also linear with regard to
the position of the referenced field, but the constant factor involved
in that is so small that this should usually not be noticed unless you
have a very large number of struct or union fields.

If performance becomes an issue but you can't or don't want to switch
to the macro API, you can improve performance by hoisting as much work
to outside of your tight loops or other performance critical sections
of your code.  E.g. if you were doing `(bytestructure-ref bs x y z)`
within a loop, you can instead do

```scheme
(let-values (((bytevector offset descriptor)
              (bytestructure-unwrap bs x y z)))
  (loop
    (bytestructure-ref* bytevector offset descriptor)))
```

or if for instance the last index in that example, `z`, changes at
every iteration of the loop, you can do

```scheme
(let-values (((bytevector offset descriptor)
              (bytestructure-unwrap bs x y)))
  (loop (for z in blah)
    (bytestructure-ref* bytevector offset descriptor z)))
```

so at least you don't repeat the indexing of `x` and `y` at every
iteration.


Following are some benchmark figures from Guile 2.2.2 on an Intel i5.
(These are only meant for a broad comparison against plain bytevector
reference.)

Prelude:

```scheme
(import
  (bytestructures guile)
  (rnrs bytevectors))
(define million-times (iota 1000000))
```

Plain bytevector reference:

```scheme
(define bv (make-bytevector 1))
(define (ref x) (bytevector-u8-ref bv 0))
,time (for-each ref million-times)
;; ~0.06s real time
```

Equivalent bytestructure reference:

```scheme
(define bs (bytestructure (bs:vector 1 uint8)))
(define (ref x) (bytestructure-ref bs 0))
,time (for-each ref million-times)
;; ~0.35s real time  (5.8 times of plain bytevector ref)
```

Showcasing the effect of a deeper structure:

```scheme
(define bs (bytestructure (bs:vector 1
                             (bs:vector 1
                               (bs:vector 1 uint8)))))
(define (ref x) (bytestructure-ref bs 0 0 0))
,time (for-each ref million-times)
;; ~0.59s real time  (9.8 times of plain bytevector ref)
```