Earlier quoted context omitted.
My test for this kind of thing is this: suppose you need to make a high speed implementation in Verilog for an FPGA or ASIC. By high speed, I mean that you need to process multiple characters per cycle (say a 64-bit word at a time)- if you have to make a decision on a byte-by-byte basis, it's too slow. This is a very possible scenario if the protocol catches on: for example, I made HDLC byte stuffing for PPP framing,…
I assume you're coming from a hardware perspective - HDLC/PPP parsing in hardware might make sense in niche cases; though most protocols benefit much more from the flexibility and upgrade possibilities of a software implementation. In this case, it is a messaging protocol. The incoming message essentially must be copied somewhere, therefore space must be allocated to store it, and therefore the length must be known.…
In hardware there is no malloc- instead there is a pool of pages and the string would be stored as a linked list of such pages. Linux socket buffers do the same thing.