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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,47bd5b7b3b898723 X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Text_IO and Ada source (was: Form feed comment for pragma Page) Date: 1996/06/11 Message-ID: <4pkp5k$13gs@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 159680608 distribution: world references: <4p04vi$3ui$1@mhafn.production.compuserve.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada Date: 1996-06-11T00:00:00+00:00 List-Id: In article , dewar@cs.nyu.edu (Robert Dewar) writes: |> Art said |> |> "In practice, of course, all of this is a non-issue, since in my compiler |> (and I expect in most compilers) both forms use the conventions for text |> files on the platform. It could be very much an issue if my program |> needed to write Ada code to be compiled on some other platform." |> |> Most, but not all, for instance, on an IBM mainframe, one would expect |> the source representation to be EBCDIC. ("both forms" = source text and run-time text I/O) But there would be a particular EBCDIC code representing the Latin-1 source-text linefeed character. The real issue is that the line-terminator would be implicit in the "logical record length" (LRECL). However, it appears to follow from RM95 2.2(2) that *both* non-tab format effectors (i.e., the EBCDIC codes representing the Latin-1 format effectors) and the end-of-record would have to be recognized as the end of a source line, so the net effect in cases such as a FF embedded in a comment would be the same as on non-EBCDIC-based systems. -- Norman H. Cohen ncohen@watson.ibm.com