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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,616091a85ff150f1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-05 06:34:26 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.27.83.146!news-FFM2.ecrc.net!news.iks-jena.de!lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: comp.lang.ada Subject: Re: Ada 200X Assertions Date: Wed, 5 Dec 2001 14:34:09 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: <3C0C48BE.3B20F04E@adaworks.com> <5ee5b646.0112040909.13a75fce@posting.google.com> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1007562849 19370 217.17.192.37 (5 Dec 2001 14:34:09 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Wed, 5 Dec 2001 14:34:09 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Xref: archiver1.google.com comp.lang.ada:17440 Date: 2001-12-05T14:34:09+00:00 List-Id: * Robert Dewar wrote: >lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:... >> I'd like to see a additional Byte_Order type and attribute to >> specify the most common byte orders indepenent from the used bit >> order. > >A lot of people want some magic here, but in fact it is very difficult to >design a coherent language feature (i.e. the step from the rough idea, >which has been often expressed, to a detailed proposal which holds water. So I'm not too far away from a 'required' feature. ;-) >No one has achieved this yet. Someone needs to have something to propose >first. And is not good exhorting others to work on this, they have and not >solved the problem. I personally don't think you can have a general >solution for many reasons, so the issue is simply whether you can have a >partial solution. That's the best starting point for a AdaYY feature. ;-) >One thing we did in Realia COBOL was simply to have big and little endian >types (e.g. consider allowing bit order to be specified for integer >types). That's quite useful for some of these cases, but magic is out :-) The compiler should be able to generate code with endinaess prefixes directly. That's all. No magic. >Now the default representation of this in GNAT (and in any reasonable >compiler) is: > >for pascal_string'Object_Size use 2048; >for pascal_string'Value_Size use (((#1 max 0) * 8) + 8) ; >for pascal_string'Alignment use 1; >for pascal_string use record > len at 0 range 0 .. 7; > data at 1 range 0 .. ((#1 max 0) * 8) - 1; >end record; Exactly this should be specifyable. >Yes, it would be nice to have a way of specifying this >for sure, but it is hardly a critical problem in practice. Sometimes (i.e. IPV4 Header) it would solve a lot, because I'd could use the record instrinct discriminiants directly: for ipv4 use record ... head_len at 0 range 0 .. 3; ... options at 40 range 0 .. (8 * (head_len - 5)); payload at 8*head_len range 0 .. (8 * len); end record; >This solution won't fly at all, it is has horrible implications, since the >situations in which expressions of this kind could be used are very >limited, and the list of rules would be junk. For example, if you allow > > len at 0 range 7+len; > >you have a huge mess on your hands. I do not see the mess. >So your solution here is the wrong solution to the problem. I would guess >it would be good enough to simply be able to give the static starting >position perhaps something like > > data at 1 range 0 .. <>; > >where the meaning of <> is that you will let the compiler choose. Yep, if I can set a discriminant depend starting position.