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!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Operating System differences and Ada OS independent programming Date: Tue, 22 Mar 2016 20:06:07 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <56eff4a4$0$4238$e4fe514c@news.kpn.nl> NNTP-Posting-Host: LMk7+sG0YqgPmReI4fVkAA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29848 Date: 2016-03-22T20:06:07+01:00 List-Id: On 2016-03-22 16:08, G.B. wrote: > On 22.03.16 14:40, Dmitry A. Kazakov wrote: > >>> Would this be real: >>> >>> 1. Take a zipped archive, produced by a real ZIP program, >>> of an Ada program's file system hierarchy on System A. >>> >>> 2. unzip in the same manner on System B. >>> >>> 3. Expect Ada's (not yet real) file system related types >>> to handle the files thus transported. >> >> Sure. > > I take it that the certainty refers to "real". OK. Yes, it is real. >> Considering that file paths have equivalents in the given file >> system = an implementation is possible [*]. There would be no problem. > > Except that possible /= real yet: Do we get there without > making ZIP aware of Ada's data representation needs? Yes. The requirement, again, is that it would be possible to do = ZIP's internal representation of paths would allows packing and then unpacking file in question. If it does, there is no problem to create that ZIP's representation from Ada's object and conversely create an object from the representation. It is all about serialization, nothing to do with files. > Or without making the file system a typed file system, > for that matter? The properties of the file system are of no interest, so long the equivalent paths exist. >> And in general, what your concern might be, is unrelated to the problem >> at hand. You are talking about serializing/deserializing some language >> object. This problem is independent on what the object is supposed to >> be. > > Alas, mentioning that an object is supposed to be something > does not say what it should be in any interpretation. Any interpretation of what? > Related question: What is a proper description of the "Form" > parameters of Ada's I/O routines, in terms of a standard Ada > type, or several standard Ada types? The proper description of the "Form" parameters is a "hack", "bad design". Obviously there should be no such thing. If the user wants some system-dependent stuff he is welcome to use system API. Annex Interfaces.C is his friend. >> BTW, you forgot: >> >> 4. Pack it again and make sure that the new archive is exactly same. > > Isn't the symmetry (modulo time stamps) already a consequence > of A and B not being specific? The normalization issue. Under Windows file names are case-insensitive. For an implementation to be useful, no symmetry is required. There are classes of equivalence of file names under practically *any* OS/file system. Therefore no symmetry is possible even in theory. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de