commit 6862cd38a59685d15f9940fcf3882607081e3261
author Neels Hofmeyr <neels@hofmeyr.de> Sun Sep 13 23:56:21 2020 +0200
committer laforge <laforge@osmocom.org> Mon Sep 14 11:53:46 2020 +0000
tree b05eb7f328c4fb5d0d4dc5e9aeb5553d12b3ba25
parent c0ac4e37c90149785b6fa77a59bb609a46474582

bitXXgen: add bitgen_test.c

The autogenerated bitXXgen.h headers for osmo_load16le_ext() thru
osmo_store64_be() are not actually tested at all. Add a test.

The test output shows that the osmo_load*be_ext for a shorter len do not return
nicely matching results. A practical example showing the difficulty in storing
and loading 24bit integer values as/from big-endian:

	uint8_t buf[4];
	memset(buf, 0, sizeof(buf));
	osmo_store32be_ext(0x00112233, buf, 3); // stores 11 22 33
	printf("%s\n", osmo_hexdump(buf, 4));
	uint32_t r = osmo_load32be_ext(buf, 3); // returns 0x11223300, not 0x00112233
	printf("0x%x\n", r);

output is:

	11 22 33 00
	0x11223300

In contrast, the little-endian variant properly aligns the loaded bytes on the
least significant octet:

	uint8_t buf[4];
	memset(buf, 0, sizeof(buf));
	osmo_store32le_ext(0x00112233, buf, 3); // stores 33 22 11
	printf("%s\n", osmo_hexdump(buf, 4));
	uint32_t r = osmo_load32le_ext(buf, 3); // returns 0x00112233 as expected
	printf("0x%x\n", r);

output for le is:

	33 22 11 00
	0x112233

Change-Id: I5542ace54376a206aa8574812d4c742c86c293b4