Typed items and the 'C' bit

[Jonathan S. Shapiro]

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?
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC