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!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Simple Data Endianness Date: Thu, 13 Feb 2020 18:29:37 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2a19cdb1-6f01-4b1d-8597-b6ee21ed60ed@googlegroups.com> <9d6d22b8-3771-47ac-901f-e593237fe108@googlegroups.com> NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58055 Date: 2020-02-13T18:29:37+01:00 List-Id: On 2020-02-13 17:47, Optikos wrote: > On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazakov wrote: >> On 2020-02-13 16:12, Optikos wrote: >>> On Thursday, February 13, 2020 at 5:10:44 AM UTC-6, Dmitry A. Kazakov wrote: >>>> On 2020-02-13 10:42, guijarrockGuijarro wrote: >>>> >>>>> The problem I present today is related to the coexistence between big-endian and little-endian application data. >>>> >>>> How low-level representation aspect might be relevant to application data? >>> >>> If the exchange of app data between 2 or more computers is word-wise binary instead of byte-wise textual, such as via binary-formatted files or via binary-formatted datagrams/byte-streams as payload of networking protocols. >> >> And how whatever protocol encoding format is could to "coexist" (?) with >> another itself (?) >> >> In any case it has nothing to do with application data as kept in the >> memory. > > Even your facetious example of app-data exchanged in Mayan numerals stored in GIF images needs to be in DRAM for encoding and decoding the app-data to other modules of software elsewhere in the app. Nope. The point is that application must keep its objects of an enumeration type using the representation chosen by the compiler. It is not programmer's business. Representation clauses should never be misused for the purpose of external encoding even when that might per chance work. In most cases it does not, and it is good so. >> BTW, supposing the exchange protocol happens to be Mayan numerals stored >> in GIF images. What representation clause we need in Ada for that? > > When Ada has Mayan numerals and GIF images as 1st-class citizens in the core language (i.e., not even the standard library), then, yes, Ada would need to have representation clauses for them. Obviously, this would be a major disincentive to standardizing Mayan numeral and GIF images in the core language. Perhaps you could submit an AI on an 01 April of some year to see how far the AI gets in the process. I would rather go for Sumerian numerals first... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de