27.01.2016 20:49, Holger Freyther пишет:
Be more specific here. Which routines were impacted? Sure all calls to bitvec_write_field.
bitvec_unhex() is the only consumer in libosmocore for bitvec_write_field() so far
Why do you decide to not make this variable an in+out variable and instead need to know how many spaces it advanced?
I've tested that approach as well but it makes code much harder to read without providing any real benefits.
Have you checked the other code that was converted?
Yes, the only potentially problematic functions are bitvec_*_field()
Extend the test to see what happens if you unhex more than d can hold?
Will do.
Instead of dumping up to 64bytes can you see how many bytes are filled?
The functions for that are part of another patch currently under review as well. I did not wanted to reimplement them just for one test-case. I can extend this once it's merged.
so if you take the "unsigned&" and make it a plain variable then the write_index += len at the end mkes no sense and can be removed?
Yes. In the patch in question I instead return write_index+len to make it easier for caller.
cheers, Max.