Best practice for function to handle 1-256 bytes

Answer 1

Your inner function should copy count + 1 bytes, e.g.,

 do /* copy one byte */ while(count-- != 0);

If the post-decrement is slow, other alternatives are:

 ... /* copy one byte */
 while (count != 0) { /* copy one byte */; count -= 1; }

or

 for (;;) { /* copy one byte */; if (count == 0) break; count -= 1; }

The caller/wrapper can do:

if (count > 0 && count <= 256) inner((uint8_t)(count-1))

or

if (((unsigned )(count - 1)) < 256u) inner((uint8_t)(count-1))

if its faster in your compiler.

Answer 2

If an int parameter costs 3 instructions and a char parameter costs 1, you could pass an extra char parameter for the extra 1 bit you're missing. It seems pretty silly that your (presumably 16-bit) int takes more than twice as many instructions as an 8-bit char.

Answer 3

FWIW, I'd choose some variant of option #1. The function's interface remains sensible, intuitive, and seems less likely to be called incorrectly (you might want to think about what you want to do if a value larger than 256 is passed in - a debug-build-only assertion might be appropriate).

I don't think the minor 'hack'/micro-optimization to loop the correct number of times using an 8-bit counter would really be a maintenance problem, and it seems you've done considerable analysis to justify it.

I wouldn't argue against wrappers if someone preferred them, but I'd personally lean toward option 1 ever-so-slightly.

However, I would argue against having the public interface require the caller to pass in a value one less than they wanted to read.