The L4.x2 specification states:

1. The 'C' bits of typed items and the 't' field of IPW0 redundantly encode the number of typed items. This is intentional.

2. The sender ignores the 'C' bits, but sets them for the receiver.

[This is required because the sender may set the C bits incorrectly, and the path in the kernel that interprets them must have a small, bounded number of iterations. If the kernel believes the 'C' bits of the type field, a very large number of iterations could be created and the receiver-side "frame" for words could be overwritten by the sender.]

3. The specifcation *alleges* that the C bit provides a performance advantage to the receiver in parsing the arguments.

I am not convinced that [3] is true. The typed items have variable length, which means that the receiver must parse the type fields in order to iterate over them. The only complex case is string items having a non-zero 'c' (continue) bit, and the specification is explicit that for these cases the "type" field of the successor stringitem is entirely ignored.

Question: does the 'C' bit provide a real advantage, or is it a historical curiosity? If there is an advantage, can somebody give an example?