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.
