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!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: quiz for Sequential_IO Read Date: Mon, 4 Sep 2017 09:37:41 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.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.3.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: feeder.eternal-september.org comp.lang.ada:16837 Date: 2017-09-04T09:37:41+02:00 List-Id: On 03/09/2017 22:10, Frank Buss wrote: > On 09/03/2017 07:28 PM, J-P. Rosen wrote: >> Le 03/09/2017 à 13:01, Frank Buss a écrit : >>> The content of test.txt is just the ASCII string "hello": >> If it is a text file, it is not appropriate for Sequential_IO which >> requires a binary file. > > It was just an example, and I posted the binary content of the file for > clarification as well. > >> In every language, the format of a binary file is known only to the >> compiler (I remember having been warned about this when I learned >> FORTRAN - a long time ago); the purpose of these files is to save data, >> then reread them from the same program, or at least the same language >> with the same compiler. > > This is nonsense. There are a lot of binary file specifications and of > course it should be possible to read and write these files, independent > of the programming language or the compiler. Imagine files like PNG > would only work, if you write/read them with a program, which was > compiled with exact the same compiler. That is not same. You can have OS/platform/application-specific format and you can have a universal one. Taking your example, imagine a JPEG file in place of PNG. Even if the object type is same (image) the binary format may be any. Ada's implementation of sequential I/O is not required to be portable. An implementation is free to choose whatever it considers suitable. In must cases it would just be the memory representation, maybe, aligned to external storage elements margin. In terms of images, it is like storing image the way it is kept in the video memory. >> It may happen that the compiler just outputs the raw binary >> representation, but you have absolutely no guarantee about that. > > Any programming language implementation which doesn't provide exact > binary input/output is unusable. It might be fine for some rare cases, > where you need it only in the same program that the binary > representation doesn't matter (e.g. temporary cache files etc.), but > usually you want to have control over the format and you want to know > the format. That is the point. Ada has no control on whatever binary formats. So whatever representation it might mandate for sequential I/O that would not fit anyway. So a pragmatic decision was made not to require anything. If you want to implement some specific format then stream I/O is the best available choice. You may still have issues on strange platforms where Stream_Element is not octet, but these are rare. In days before stream I/O sequential I/O was used in a way that blocks of octets were the elements and the actual types were encoded into these blocks to make the format portable. That is not very different from how you would use stream I/O, but the latter is far more comfortable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de