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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? Date: Wed, 30 May 2018 14:38:47 -0500 Organization: JSA Research & Innovation Message-ID: References: <5f1e44fa-5b78-45a1-a12e-b8089d823540@googlegroups.com><9ae54be5-0b96-4675-ad95-7a61ecc6fbd0@googlegroups.com> Injection-Date: Wed, 30 May 2018 19:39:00 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="1820"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:52786 Date: 2018-05-30T14:38:47-05:00 List-Id: "Simon Wright" wrote in message news:lysh69hcl0.fsf@pushface.org... > "Randy Brukardt" writes: > >> "Simon Wright" wrote in message >> news:ly4litj7qx.fsf@pushface.org... > >>> But it doesn't do byte swapping. >> >> Thank goodness. People use rep. clauses all the time in code that >> permeates an entire program; having very expensive byte swapping code >> easily triggered would give Ada a reputation of being a slug (rather >> than understanding that the code misuses the features). The whole idea >> of portable representation clauses is close to misuse of the feature >> (the entire value is to ensure that compilers for the same target >> intepret the clauses the same way). > > (a) In that case, the LRM should point out this potential problem in red > block caps; or eliminate rep clauses altogether and make us use C-style > shifts and masks (I think that's what Dmitry does anyway). Rep. clauses are very useful where byte swaps are not needed (even there, though, it is best to avoid them in code that needs to have highest performance). And it's impossible to legislate good program design in a programming language -- but that doesn't mean that we have to encourage bad design. > (b) My experience of rep clauses is communication with other machines, > be they NTP time servers over a network or hardware interface cards. I > don't understand "ensure that compilers for the same target intepret the > clauses the same way". I assume that a single compiler will always interpret rep. clauses the same way (otherwise, that would be very unfriendly to their customers). But there are lots of things in Ada (or any other programming language), if left to their own interpretation, will end up different for different compilers even for the same target. (For example, the exact interpretation of file names). The point of Claw, of instance, was to work on *all* Windows Ada compilers, and for that, rep. clauses, pragma Import, and a variety of other things have to work the same way. And that was a struggle - even a premimum vendor that truly cared like Rational in the late 1990s got lots of things wrong/not portable. Most of the value of Ada's portability features is to prevent vendor lock-in, so you can move your code to a new vendor without having to make a lot of code changes. When the target changes (especially the processor), that advantage is much less, since all of those things that prevent real portability are going to be different anyway. I'm sure there are occassional exceptions here and there (there *always* are exceptions to any rule!), but those are much less likely. (Ada is quite portable even without that target-specific stuff that's almost never portable, but that requires careful program design to keep the things likely to be different very isolated.) Randy.