casado@enstb.enst-bretagne.fr (casado) (06/06/90)
Imagine this scenario on one computer: There are two different Ada compilers, C_A and C_B; There is a source program to create a direct file F, P_C. There is a source program to read a direct file F, P_R. P_C is compiled by C_A to obtain a object program P_C_A. P_C is compiled by C_B to obtain a object program P_C_B. P_R is compiled by C_A to obtain a object program P_R_A. P_R is compiled by C_B to obtain a object program P_R_B. P_C_A is executed to produce the file F_A. P_C_B is executed to produce the file F_B. F_A is read by P_R_A and no problem is detected. This is normal. F_B is read by P_R_B and no problem is detected. This is normal. F_A is read by P_R_B and problems are detected. Is this normal? F_B is read by P_R_A and problems are detected. Is this normal? The problems detected were to read meaningless data when the file has been created by a program that was compiled by a different compiler. Has anybody tried this scenario? I did it when I compiled a Pretty_printer that one friend had modified. The compiler utilized by my friend and the one I utilized come from different manufacturer. He created several parameters files for his Pretty_Printer. My Pretty_printer read these files, but the data contained in them were meaningless so my Pretty_printed aborted the execution.I had to create these files with the programs compiled by my compiler. Later, I searched in the LRM, and in <14.1:7> you can read: The language does not define what happens to external files after the completion of the main program (in particular, if corresponding files have not been closed). The effect of input_output for access types is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation-depended. ^^^^^^^^^^^^^^^^^^^^^^^ I have concluded that this kind of subtleties must be normalized if we want to mix tools coming from different manufactures. I do not want to imagine how many time the people is wasting on this kind of problems. Do you think that this must be normalized? Luis M. Casado /----------------------------------------------------------------------------/ / Luis M. Casado Diaz, | E-mail: casado@enstb.enst-bretagne.fr / / Departament de Informatique, | Tel: +(33) 98 00 16 33 / / E.N.S.T. Bretagne, | Fax: +(33) 98 45 51 33 / / B.P.:832, | / / 29285 BREST Cedex. | / / France. | / /____________________________________________________________________________/
eachus@linus.mitre.org (Robert I. Eachus) (06/09/90)
In article <313@enstb.enst-bretagne.fr> casado@enstb.enst-bretagne.fr (casado) writes: > The problems detected were to read meaningless data when the file > has been created by a program that was compiled by a different compiler. > Has anybody tried this scenario? This is a very good question, but not an easy one to answer. What an external file looks like is not in the domain of the Ada standard (there are other ANSI and ISO standards on the subject), and therefore it is difficult for the RM to mandate a bit layout in an external file. Most Ada compiler vendors do a good job of mapping TEXT_IO onto the standard text file formats for a particular architecture, but when it come to DIRECT_IO and SEQUENTIAL_IO the situation gets much messier. The easiest thing for a compiler to do is to provide generic IO packages which copy the internal representations of objects to external files unchanged. However different vendors will layout the same record type differently even on the same hardware, but the bigger differences are in two different ways to handle discriminated records and unconstrained array objects. Defining a record type EXACTLY with representation clauses is often enough to make files portable between compilers, but I have had trouble getting ANSI standard text files from a VAX running VMS to a VAX running Ultrix, even when using ANSI standard labelled tapes. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...