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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a05:620a:15ba:: with SMTP id f26mr6678834qkk.285.1581778617480; Sat, 15 Feb 2020 06:56:57 -0800 (PST) X-Received: by 2002:a9d:75cf:: with SMTP id c15mr6131430otl.332.1581778617179; Sat, 15 Feb 2020 06:56:57 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 15 Feb 2020 06:56:56 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <2a19cdb1-6f01-4b1d-8597-b6ee21ed60ed@googlegroups.com> <9d6d22b8-3771-47ac-901f-e593237fe108@googlegroups.com> <243d7e76-a4e3-4974-88b2-5fd699755e9a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7484fdb6-3020-4b25-9b96-b474df17430f@googlegroups.com> Subject: Re: Simple Data Endianness From: Optikos Injection-Date: Sat, 15 Feb 2020 14:56:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58075 Date: 2020-02-15T06:56:56-08:00 List-Id: On Friday, February 14, 2020 at 2:22:23 PM UTC-6, Dmitry A. Kazakov wrote: > On 2020-02-14 18:25, Optikos wrote: > > On Friday, February 14, 2020 at 2:20:40 AM UTC-6, Dmitry A. Kazakov wro= te: > >> On 2020-02-13 21:36, Optikos wrote: > >>> On Thursday, February 13, 2020 at 11:29:46 AM UTC-6, Dmitry A. Kazako= v wrote: > >>>> On 2020-02-13 17:47, Optikos wrote: > >>>>> On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazak= ov wrote: > >>>>>> On 2020-02-13 16:12, Optikos wrote: > >>>>>>> On Thursday, February 13, 2020 at 5:10:44 AM UTC-6, Dmitry A. Kaz= akov wrote: > >>>>>>>> On 2020-02-13 10:42, guijarrockGuijarro wrote: > >>>>>>>> > >>>>>>>>> The problem I present today is related to the coexistence betwe= en big-endian and little-endian > >>>>>>>>> application data. > >>>>>>>> > >>>>>>>> How low-level representation aspect might be relevant to applica= tion data? > >>>>>>> > >>>>>>> If the exchange of app data between 2 or more computers is word-w= ise binary instead of byte-wise > >>>>>>> textual, such as via binary-formatted files or via binary-formatt= ed 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. > >>> > >>> I reiterate: Even your facetious example of app-data exchanged in Ma= yan numerals stored in GIF images needs to be in DRAM =E2=80=A2=E2=80=A2=E2= =80=A2at some point, even if for a passing transient momentary instant (e.g= ., local to a procedure or function; or in a I/O buffer; or in preparation = to conform to the GUI API's expectations)=E2=80=A2=E2=80=A2=E2=80=A2 for en= coding and decoding the app-data to other modules of software elsewhere in = the app. > >> > >> No. That is technically wrong. A communication artifact does not need = to > >> be in the memory in order to be encoded or decoded. In fact it is rath= er > >> an exception, even for integers. E.g. when an integer is encoded using= a > >> chained code. So, if GIFs were used for the purpose they would be > >> encoded/decoded incrementally. > >=20 > > No, you are factually incorrect in the technical domain. Even if strea= ming binary app-data piecemeal to evermore-accumulated content of a transie= nt buffer, >=20 > [...] >=20 > I don't know what you mean. Now there is a correct statement.