Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 10/05/2018 22:06, Dan'l Miller wrote:

> LoL!!  Oh, do tell why a representation clause on an IETF packet's header layout is “useless”.

Because the language of representation clauses is too weak to handle 
layouts. One could design and integrate a full blown data-definition 
language (with conditional and looping constructs) into Ada but that 
would be a gigantic waste of time. It just does not make sense. The 
result of this are data types one cannot use effectively. To name a few 
examples from real life:

1. Integer types with reserved bit-patterns for exceptional states. E.g. 
16#FFFF#, 16#FFFE#, 16#FFFD# are not numbers but states of the hardware.

2. Non-contiguous integers. E.g. low-order 16 bits in one word, 
high-order 8 bits in a word two words ahead.

3. Middle-endian numbers.

4. Non-2's complement signed integer numbers

Therefore the programmer must copy them into machine-friendly Ada native 
types anyway. It is simpler to do this right while encoding/decoding the 
packet.

Then there is error handling and sanity checks issues which 
representation clauses do not do. So the programmer will get some 
rubbish in the memory *already* interpreted as a valid value of Ada 
type. Read - the type system breach. He must then re-check everything 
inside by re-scanning the I/O buffer one more time, because X'Valid is 
no help here.

Furthermore, representation clauses require complete packet or its parts 
read into the buffer or written away. Communication, e.g. asynchronous 
I/O just does not work this way. The application must deal with data 
chunks of almost arbitrary length. Representation clauses would require 
additional assembling/disassembling of data into chunks and thus extra 
copying.

Ergo. It works for a few cases on paper. In real life it is simpler, 
faster, safer and cleaner not to use representation clauses at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de