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.