<div dir="ltr">After feedback in IRC, I will drop this idea, and try to go the kernel way, supporting endianess annotated structures with sparse rules checking.<div><br></div><div><a href="https://lwn.net/Articles/205624/" target="_blank">https://lwn.net/Articles/205624/</a></div><div><br></div><div>The motivation is that it's really difficult to keep in sync all the format strings, and although there may be ways to deal with it, I rather prefer this other design.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 5, 2015 at 10:25 AM Javier Domingo Cansino <<a href="mailto:javierdo1@gmail.com" target="_blank">javierdo1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I have been asked for examples and use cases. Github repo has been updated.</div><div><br></div><div>I do also have doubts on if it's worth it. If a library like this existed I would be definitely using it, make conversions, does take care of alignment, can manage unaligned data and endianness. etc.</div><div><br></div><div>But I am not really sure if someone apart from me would find it interesting (long time ago I haven't seen a protocol unaligned with different endianess).</div><div><br></div><div>Waiting for your feedback!</div><div><br></div><div><pre style="color:rgb(0,0,0);line-height:normal">/*
 * Syntax for the function is as follows.
 *   %[p][n][a][lb][01r]{i,y,w,d,q,s}
 *   
 *   All the characters that don't follow this will be treated as raw chars
 *   to be written as they are.
 *
 * Data type
 *   * i - bit
 *   * y - byte
 *   * w - 2 byte word
 *   * d - 4 byte word
 *   * q - 8 byte word
 *   * s - string without termination (use strlen()+1 in quantity to null)
 *
 * Data value
 *   * 0 - fill the specified space with zeros
 *   * 1 - fill the specified space with ones
 *   * r - fill the specified space with random data
 *
 *   String data type is not valid in this case. When quantity is also
 *   specified, use l/b to separate: %5b0 -> 5 bits of value 0
 *
 * Endianess. No conversion by default
 *   * l - little endian
 *   * b - big endian
 *
 * Alignment. No alignment by default
 *   * a - align this to it's datatype
 *         bits are aligned to byte
 *
 * Quantity. One by default
 *   * n - number of same datatype (placed together)
 *         this denotes length of string, padded with 0
 *
 * Pointer. Default everything is passed by value
 *   * p - specify that passed parameter is a pointer to value(s)
 *
 *   Obviously, when quantity is specified, and datatype is not bits, p
 *   is required.
 *
 * Some examples:
 *   * %4lw - 4 little endian 2 byte word
 *   * %2i  - 2 bits 'ab' from value b'000000ab'
 *   * %2bi - 2 bits 'ab' from value b'000000ba'
 *   * %2li - 2 bits 'ab' from value b'ab000000'
 *   * %5y
 *
 * Calling functions example:
 * int32_t dw[]=[1,2,3,4]
 *
 * v = writebv("%lw%2i%ay%p4d", 2047, 3, 'n', dw);
 *
 * in a big endian computer
 * // *v = 0xff07c06e00000001000000020000000300000004
 *
 * struct my_data_t {
 *   uint16_t a;
 *   uint8_t b:2;
 *   uint8_t unused1:6;
 *   uint8_t c;
 *   uint32_t d[4];
 * } *my_data;
 * char letter;
 *
 * // If we want to have all extracted from the blob
 * my_data = readbv(v, "%lw%2i%ay%p4d");
 *
 * // If we just want to extract the char
 * readb(v, "%0w%2l0i%ay%4l0d", &letter);
 *
 * // We have aligned data, but if we removed the 'a' from %ay, we
 * wouldn't have unaligned data and this would still work.
 *
 */
</pre></div><div><br></div></div></blockquote></div></div>