osmocom
/
libosmocore
mirror of https://gerrit.osmocom.org/libosmocore
14
0
Fork 1
Code Issues Releases Wiki Activity
libosmocore/tests/bitvec/bitvec_test.ok

18 lines
1.1 KiB
Plaintext
Raw Normal View History

bitvec: Add get/set byte sequences The new functions bitvec_get_bytes and bitvec_set_bytes copy byte sequences from bitvecs to uint8_t arrays and vice versa. While the bytes in the bitvecs do not need to be aligned, the uint8_t arrays always are. In case the bytes in the bitvec are aligned, the implementation uses memcpy. Note that the implementation like the other existing functions assume MSB first encoding. [hfreyther: Squash the comment fix into this commit as well] Sponsored-by: On-Waves ehf
2015-12-21 15:04:03 +00:00
=== start test_byte_ops ===
=== end test_byte_ops ===
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
1 -=> cur_bit=184
bitvec: Test and fix regression for C++->C conversion bitvec_read_field/bitvec_write_field in the PCU used a C++ reference and when porting to C it was decided to pass the parameter by value and this lost the "back propagation" of the new index. Change the parameter to be an in/out parameter and this way do not have a silent semantic break in the osmo-pcu (where we copy the reference in csn.1 by value) and have a true compile failure. Add Max's simple test for bitvec_unhex function leaving the checking of bitvec_read_field and the side effect in the datastructure about the number of bits still open.
2016-01-30 09:54:43 +00:00
48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b
1 -=> cur_bit=184
bitvec: Test and fix regression for C++->C conversion bitvec_read_field/bitvec_write_field in the PCU used a C++ reference and when porting to C it was decided to pass the parameter by value and this lost the "back propagation" of the new index. Change the parameter to be an in/out parameter and this way do not have a silent semantic break in the osmo-pcu (where we copy the reference in csn.1 by value) and have a true compile failure. Add Max's simple test for bitvec_unhex function leaving the checking of bitvec_read_field and the side effect in the datastructure about the number of bits still open.
2016-01-30 09:54:43 +00:00
47240c00400000000000000079eb2ac9402b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
47240c00400000000000000079eb2ac9402b2b2b2b2b2b
1 -=> cur_bit=184
bitvec: Test and fix regression for C++->C conversion bitvec_read_field/bitvec_write_field in the PCU used a C++ reference and when porting to C it was decided to pass the parameter by value and this lost the "back propagation" of the new index. Change the parameter to be an in/out parameter and this way do not have a silent semantic break in the osmo-pcu (where we copy the reference in csn.1 by value) and have a true compile failure. Add Max's simple test for bitvec_unhex function leaving the checking of bitvec_read_field and the side effect in the datastructure about the number of bits still open.
2016-01-30 09:54:43 +00:00
47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b
1 -=> cur_bit=184
bitvec: Test and fix regression for C++->C conversion bitvec_read_field/bitvec_write_field in the PCU used a C++ reference and when porting to C it was decided to pass the parameter by value and this lost the "back propagation" of the new index. Change the parameter to be an in/out parameter and this way do not have a silent semantic break in the osmo-pcu (where we copy the reference in csn.1 by value) and have a true compile failure. Add Max's simple test for bitvec_unhex function leaving the checking of bitvec_read_field and the side effect in the datastructure about the number of bits still open.
2016-01-30 09:54:43 +00:00
deadface000000000000000000000000000000beeffeed0000000000000000000000000000000000000000000000000000000000000000000000000000000000
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
DEADFACE000000000000000000000000000000BEEFFEED
0 -=> cur_bit=512
bitvec: Test and fix regression for C++->C conversion bitvec_read_field/bitvec_write_field in the PCU used a C++ reference and when porting to C it was decided to pass the parameter by value and this lost the "back propagation" of the new index. Change the parameter to be an in/out parameter and this way do not have a silent semantic break in the osmo-pcu (where we copy the reference in csn.1 by value) and have a true compile failure. Add Max's simple test for bitvec_unhex function leaving the checking of bitvec_read_field and the side effect in the datastructure about the number of bits still open.
2016-01-30 09:54:43 +00:00
fffffaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bivec: Fix the output of the testcase osmo_hexdump_nospc/osmo_hexdump is an old school C routine with a static internal array. This means that printf will most likely one of the two strings twice. For Linux/glibc this is the first string (for whatever reason?) and for FreeBSD it is the last call of the osmo_hexdump_nospc. We could have noticed by both strings being of the same length besides the different length input. The second issue is that we cast a hexstring to uint8_t and dump the string as hex. So the two strings should not match at all. Fix it by printing the hex string as plain hex and separating the two printf calls. Update the test output.
2016-01-30 15:16:28 +00:00
FFFFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB