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 14:40:34 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <56eff4a4$0$4238$e4fe514c@news.kpn.nl> NNTP-Posting-Host: bqgfK7NL3xTHnr0WRaLl4g.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 6.1; 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:29842 Date: 2016-03-22T14:40:34+01:00 List-Id: On 22/03/2016 12:15, G.B. wrote: > On 22.03.16 09:43, Dmitry A. Kazakov wrote: > >> Of course, it is not normalization what is needed, but proper typing >> instead. Path is not a string. It must be a defined in the Ada standard >> type with basic operations including OS-dependent string to path >> conversion and backwards. Of course standard packages must take >> instances of the type as parameters when opening a file. This will >> eliminate most if not all real problems (as opposed to imaginary ones) >> with it. > > 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. Considering that file paths have equivalents in the given file system = an implementation is possible [*]. There would be no problem. 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. After all, a string path, is also nothing but a serialized file system entity. The problem is that the choice of how to do this serialization was not good enough if the entity should cross file system borders. BTW, you forgot: 4. Pack it again and make sure that the new archive is exactly same. ---------------- * Consider the FILES-11 file system where name is DM:[10,10]TEST.TXT with file names limited to 7 characters long and RADIX-50 character set. Of course it would be impossible to extract a file with the path of 10 levels deep there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de