From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? Date: Fri, 11 May 2018 11:40:23 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <2821b8e0-2c64-4621-b65e-337027fc121e@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:52260 Date: 2018-05-11T11:40:23+02:00 List-Id: 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