* Form feed comment for pragma Page @ 1996-06-04 0:00 Rex Reges 1996-06-03 0:00 ` Robert Dewar 1996-06-03 0:00 ` Robert Dewar 0 siblings, 2 replies; 20+ messages in thread From: Rex Reges @ 1996-06-04 0:00 UTC (permalink / raw) One unusually nonportable bit of Ada code occurs when you place a form feed character in a comment after a pragma Page: pragma page ; -- ^L (form feed for pagination during -- straight printing of the source code file) Compilers issue informationals about either: 1) Comments after pragma Page do not have to be printed in the source code. 2) The form feed character isn't in the allowed set of characters for Ada source code. It appears that problem number 1 should go away in Ada 95 because all pragmas must be printed out in the source listing. However, this may cause an extra form feed. -- or you can call me The Fixer... or you can e-mail me at RegesR@pgate.he.boeing.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-04 0:00 Form feed comment for pragma Page Rex Reges @ 1996-06-03 0:00 ` Robert Dewar 1996-06-06 0:00 ` Rex Reges 1996-06-03 0:00 ` Robert Dewar 1 sibling, 1 reply; 20+ messages in thread From: Robert Dewar @ 1996-06-03 0:00 UTC (permalink / raw) Just to be clear, if you gave the following lines pragma page ; -- ^L (form feed for pagination during -- straight printing of the source code file) to an Ada compiler, including the comments in parens, then any Ada 83 or Ada 95 compiler must flag a syntax error for the line starting (form feed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-03 0:00 ` Robert Dewar @ 1996-06-06 0:00 ` Rex Reges 1996-06-05 0:00 ` Robert Dewar 0 siblings, 1 reply; 20+ messages in thread From: Rex Reges @ 1996-06-06 0:00 UTC (permalink / raw) Yes, I verified that both the VAX and Harris's version of the Verdix compiler do accept a comment which ends in a form feed. The form feed character is a valid formatting element in the language, but is handled differently by the source code listings. The Vax prints the pragma page, pages to the next page, and then finishes the line's comment and pages again. Therefore, nothing is lost. Note that there is a slight difference between Ada 83 and 95 concerning the definition of a comment. It appeared to me that the intent was to allow almost any character code to be in the comment including nulls and other items not normally allowed. -- or you can call me The Fixer... or you can e-mail me at RegesR@pgate.he.boeing.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-06 0:00 ` Rex Reges @ 1996-06-05 0:00 ` Robert Dewar 1996-06-12 0:00 ` Rex Reges 0 siblings, 1 reply; 20+ messages in thread From: Robert Dewar @ 1996-06-05 0:00 UTC (permalink / raw) Rex said "Note that there is a slight difference between Ada 83 and 95 concerning the definition of a comment. It appeared to me that the intent was to allow almost any character code to be in the comment including nulls and other items not normally allowed." No difference between Ada 83 and Ada 95 here, an approved AI allowed (though to be precise did not require) this in Ada 83. The Ada 95 definition is merely a restatement of the conclusions of this AI. Note that ending a comment with a form feed is of course fine, since that is the end of a logcal line anyway. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-05 0:00 ` Robert Dewar @ 1996-06-12 0:00 ` Rex Reges 1996-06-12 0:00 ` Rex Reges 0 siblings, 1 reply; 20+ messages in thread From: Rex Reges @ 1996-06-12 0:00 UTC (permalink / raw) It appears to me now that the problem with a form-feed-character-in-a-comment evolved over time to a non-problem and I observed the problem before compiler vendors had caught up. Although this may seem a minor point, I would like to make some additional comments. The current Ada 95 appears to have a different problem that I have run into: null characters. In LRM 2.1 the allowed characters for comments are intentionally not defined causing trouble from one machine to another. The statement is: "The only characters allowed outside of comments are..." This may allow null characters and other troublesome control characters. One should not put a null character in a comment since the Unix debuggers tend to -- or you can call me The Fixer... or you can e-mail me at RegesR@pgate.he.boeing.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-12 0:00 ` Rex Reges @ 1996-06-12 0:00 ` Rex Reges 1996-06-12 0:00 ` Robert Dewar 1996-06-13 0:00 ` Ken Garlington 0 siblings, 2 replies; 20+ messages in thread From: Rex Reges @ 1996-06-12 0:00 UTC (permalink / raw) I was cut off! Sorry about that. As I was saying... One should not put a null character in a comment since the Unix debuggers tend to stop printing when they encounter a null. For example, when I examine strings while debugging, I have found that the full string will not be printed if a null is embedded: Example : Strin(1..7) ; Example := "ABC" & Character'Val(000) & "DEF" ; Examinging Example will result in: Example = "ABC" In addition, useful tools like Vax's CMS won't accept some control characters inthe source code (at least the old versionI am using). Therefore, my recommendation is to stick to the visible character set including foreign characters which AI-00339 was actually aimed at. Also, when debugging, examine strings in hex first to see if any nulls are lurking about. -- or you can call me The Fixer... or you can e-mail me at RegesR@pgate.he.boeing.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-12 0:00 ` Rex Reges @ 1996-06-12 0:00 ` Robert Dewar 1996-06-13 0:00 ` Ken Garlington 1 sibling, 0 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-12 0:00 UTC (permalink / raw) Rex says "Therefore, my recommendation is to stick to the visible character set including foreign characters which AI-00339 was actually aimed at. Also, when debugging, examine strings in hex first to see if any nulls are lurking about." That's not quite right, a specific intent of AI-00339 was to allow ESC sequences corresponding to typical methods of representing wide characters. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-12 0:00 ` Rex Reges 1996-06-12 0:00 ` Robert Dewar @ 1996-06-13 0:00 ` Ken Garlington 1 sibling, 0 replies; 20+ messages in thread From: Ken Garlington @ 1996-06-13 0:00 UTC (permalink / raw) > In addition, useful tools like Vax's CMS won't accept some control > characters inthe source code (at least the old versionI am using). I think this particular problem is fixed in later versions of DEC CMS (used to be VAX CMS). Later versions of CMS also allow non-text files, such as executables, to be stored. -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-04 0:00 Form feed comment for pragma Page Rex Reges 1996-06-03 0:00 ` Robert Dewar @ 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Arthur Evans Jr 1996-06-04 0:00 ` Robert A Duff 1 sibling, 2 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-03 0:00 UTC (permalink / raw) Rex said "Compilers issue informationals about either: 1) Comments after pragma Page do not have to be printed in the source code. 2) The form feed character isn't in the allowed set of characters for Ada source code. It appears that problem number 1 should go away in Ada 95 because all pragmas must be printed out in the source listing. However, this may cause an extra form feed. " First, there is no change in Ada 95 compared to Ada 83 with respect to pragma Page. Second, form feed *is* in the allowed set of characters for Ada source code, but it is a logical end of line separator, so you cannot put it in the middle of a comment (since it ends the logical line). Again, no change from 83 to 95 here. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-03 0:00 ` Robert Dewar @ 1996-06-04 0:00 ` Arthur Evans Jr 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Form feed comment for pragma Page Keith Thompson 1996-06-04 0:00 ` Robert A Duff 1 sibling, 2 replies; 20+ messages in thread From: Arthur Evans Jr @ 1996-06-04 0:00 UTC (permalink / raw) In article <dewar.833858501@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote: > Second, form feed *is* in the allowed set of characters for Ada > source code, but it is a logical-end-of line separator, so you > cannot put it in the middle of a comment (since it ends the logical line). Well, form feed (control-L) is an ASCII character and part of the standard character set, but I'm quite surprised to hear that it's a logical-end-of line, for two reasons: - If anything, it's-end-of page, not-end-of line. - And it's not even that. The RM in A.10(8) is quite clear that the standard does not specify which characters, if any, correspond to logical end-of-line or end-of-page or end-of-file. I'll agree that many implementations, probably most of them, choose to implement end-of-page using the ASCII form feed character, but the standard is silent on the subject. Art Evans Arthur Evans Jr, PhD Phone: 412-963-0839 Ada Consulting FAX: 412-963-0927 461 Fairview Road Pittsburgh PA 15238-1933 evans@evans.pgh.pa.us ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-04 0:00 ` Arthur Evans Jr @ 1996-06-04 0:00 ` Robert Dewar 1996-06-06 0:00 ` Text_IO and Ada source (was: Form feed comment for pragma Page) Arthur Evans Jr 1996-06-05 0:00 ` Form feed comment for pragma Page Keith Thompson 1 sibling, 1 reply; 20+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) Art says "Well, form feed (control-L) is an ASCII character and part of the standard character set, but I'm quite surprised to hear that it's a logical-end-of line, for two reasons: - If anything, it's-end-of page, not-end-of line. - And it's not even that. The RM in A.10(8) is quite clear that the standard does not specify which characters, if any, correspond to logical end-of-line or end-of-page or end-of-file. I'll agree that many implementations, probably most of them, choose to implement end-of-page using the ASCII form feed character, but the standard is silent on the subject." Art, you are confused, we are talking about source representation here. YOu quoted some irrelevant paragraph about Text_IO. THe operable statement in the standard is: 2.1 13 format_effector The control functions of ISO 6429 called character tabulation (HT), line tabulation (VT), carriage return (CR), line feed (LF), and form feed (FF). and 2.2 2 The text of a compilation is divided into lines. In general, the representation for an end of line is implementation defined. However, a sequence of one or more format_effectors other than character tabulation (HT) signifies at least one end of line. Pretty clear, and far from silent. It is very important to understand that source representation has nothing to do with type Standard.Character or with Text_IO. Sure, may implementations may choose to represent the source in a manner that is consistent with Text_IO as a sequence of elements of type Standard.Character, but this is not a required representation, just one possible choice. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-04 0:00 ` Robert Dewar @ 1996-06-06 0:00 ` Arthur Evans Jr 1996-06-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 20+ messages in thread From: Arthur Evans Jr @ 1996-06-06 0:00 UTC (permalink / raw) I said (among other things) > The RM in A.10(8) is quite clear that the standard does not specify > which characters, if any, correspond to logical end-of-line or > end-of-page or end-of-file. Robert Dewar (and Keith Thompson) replied > Art, you are confused, we are talking about source representation here. > YOu quoted some irrelevant paragraph about Text_IO. THe operable > statement in the standard is: 2.1(13) Absolutely right -- I missed that section. Robert goes on: > It is very important to understand that source representation has > nothing to do with type Standard.Character or with Text_IO. Sure, may > implementations may choose to represent the source in a manner that is > consistent with Text_IO as a sequence of elements of type > Standard.Character, but this is not a required representation, just > one possible choice. It's too bad in a way, though I guess inevitable, that the standards for Text_IO and source representation are not better connected. An effect is that it's not clear how to write an Ada program that emits proper Ada code -- proper in the sense that the compiler I am using will be able to read it. Indeed, the documentation of the Ada compiler I now use is silent on both of these subjects: - the exact form required for source text; and - how Text_IO treats end-of-line and such. Appendix M(6) requires that the form of source text be documented, though I see no requirement to document the details of Text_IO file format. (Curious omission...) 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. Art ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-06 0:00 ` Text_IO and Ada source (was: Form feed comment for pragma Page) Arthur Evans Jr @ 1996-06-06 0:00 ` Robert Dewar 1996-06-11 0:00 ` Norman H. Cohen 1996-06-18 0:00 ` Norman H. Cohen 0 siblings, 2 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-06 0:00 ` Robert Dewar @ 1996-06-11 0:00 ` Norman H. Cohen 1996-06-12 0:00 ` Robert Dewar 1996-06-18 0:00 ` Norman H. Cohen 1 sibling, 1 reply; 20+ messages in thread From: Norman H. Cohen @ 1996-06-11 0:00 UTC (permalink / raw) In article <dewar.834075532@schonberg>, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-11 0:00 ` Norman H. Cohen @ 1996-06-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-12 0:00 UTC (permalink / raw) Norman said "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. " What is your justification for the first sentence here. I read nothing in the RM that requires or implies that the source representation of any format effector is a "particular code", EBCDIC or otherwise. For example, a perfectly legitimate representation of form feed is some special mark in the record, or even a conventional carriage control character (i.e. a '1', remember that?) at the start of the record. The standard has NOTHING AT ALL to say about source representation. FOr examle, a quite legitimate source representation is to store the source as a tree, and indeed in one sense that is exactly what he Rational system does. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-06 0:00 ` Robert Dewar 1996-06-11 0:00 ` Norman H. Cohen @ 1996-06-18 0:00 ` Norman H. Cohen 1996-06-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 20+ messages in thread From: Norman H. Cohen @ 1996-06-18 0:00 UTC (permalink / raw) In article <dewar.834585066@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: |> Norman said |> |> "But there would be a particular EBCDIC code representing the Latin-1 |> source-text linefeed character. ... |> " |> |> What is your justification for the first sentence here. I read nothing |> in the RM that requires or implies that the source representation of |> any format effector is a "particular code", EBCDIC or otherwise. ... |> The standard has NOTHING AT ALL to say about source representation. Quite right, I was describing actual practice, not any requirement of the standard. (The usual practice is to exploit the operating system's division of files into logical records and to treat each record as a source line, but it is possible to sneak format effectors--or, more precisely, EBCDIC characters that the implementation treats as the representation of ISO 10646 BMP format effectors--into the middle of a record.) What RM95 2.2(2) requires is that, whatever mechanisms the implementation uses to represent a format effector other than a tab, the implementation must treat the logical occurrence of such a character as the end of a line, i.e., such a character cannot be construed as occurring in the MIDDLE of a comment. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Text_IO and Ada source (was: Form feed comment for pragma Page) 1996-06-18 0:00 ` Norman H. Cohen @ 1996-06-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-20 0:00 UTC (permalink / raw) Norm Cohen says "What RM95 2.2(2) requires is that, whatever mechanisms the implementation uses to represent a format effector other than a tab, the implementation must treat the logical occurrence of such a character as the end of a line, i.e., such a character cannot be construed as occurring in the MIDDLE of a comment." There is nothing to say that "the mechanism the implementation uses to represent a format effector" has anything to do with any characters in the source text (in Norm's message here, he is using character in the logical sense). For example, the following is peculiar, but quite legitimate: A form feed format effector character could be the character 16#0C# provided that it occurs outside a comment, but inside a comment 16#0C# could be regarded as not being a format effector. The occurrence of a form feed terminating a comment (which must be permissible) could be represented by some entirely different mechanism. There is nothing in the RM to say that the method used for source representation must be a simple one-to-one translation of some kind, though of course in many systems this will indeed be the case. Note that in particular, it is perfectly fine to represent all format effectors that terminate a line in an identical manner, since they all have identical lexical/syntactic/semantic effects. For example, it is perfectly fine on the IBM mainframe to represent CR, LF, VT, or FF or any sequence of such characters as the physical end of record, without distinguishing between these cases. In a Unix-based system, it would be peculiar, but perfectly permissible to represent CR,LF,VT and FF (here and in the previous paragraph I am using these abbreviations to abbreviate the logical Ada characters, not the corresponding ascii representations), the same way. For example, you can take the Ada source, and translate CR,LF,VT,FF all to LF, and that is a legitimate source representation, since every possible Ada program is representable, and has correct semantics. You can take this much further, for example, all comments can be represented by a single space in the text that is input to your compiler. Of course, good taste and usability dictate against choosing source representations that are undesirable or unworkable, but the RM itself dictates *very* little in this area! ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-04 0:00 ` Arthur Evans Jr 1996-06-04 0:00 ` Robert Dewar @ 1996-06-05 0:00 ` Keith Thompson 1 sibling, 0 replies; 20+ messages in thread From: Keith Thompson @ 1996-06-05 0:00 UTC (permalink / raw) In <evans-0406961641500001@ppp5.pgh.net> evans@evans.pgh.pa.us (Arthur Evans Jr) writes: > Well, form feed (control-L) is an ASCII character and part of the > standard character set, but I'm quite surprised to hear that it's a > logical-end-of line, for two reasons: > > - If anything, it's-end-of page, not-end-of line. > > - And it's not even that. The RM in A.10(8) is quite clear that the > standard does not specify which characters, if any, correspond to > logical end-of-line or end-of-page or end-of-file. > > I'll agree that many implementations, probably most of them, choose to > implement end-of-page using the ASCII form feed character, but the > standard is silent on the subject. RM A.10(8) refers to files processed by Text_IO, not to Ada source files; there's no requirement that they're the same thing. An Ada compiler needn't use Text_IO to read source files. The relevant paragraph is 2.2(2), which says: The text of a compilation is divided into lines. In general, the representation for an end of line is implementation defined. However, a sequence of one or more format_effectors other than character tabulation (HT) signifies at least one end of line. A format_effector is defined in 2.1(13) as one of HT, VT, CR, LF, and FF. Thus a formfeed character *in an Ada source* must signify an end of line. Note that the coded representation for these characters is also implementation-defined. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Arthur Evans Jr @ 1996-06-04 0:00 ` Robert A Duff 1996-06-04 0:00 ` Robert Dewar 1 sibling, 1 reply; 20+ messages in thread From: Robert A Duff @ 1996-06-04 0:00 UTC (permalink / raw) In article <dewar.833858501@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Second, form feed *is* in the allowed set of characters for Ada >source code, but it is a logical end of line separator, so you >cannot put it in the middle of a comment (since it ends the logical line). >Again, no change from 83 to 95 here. Quite true, but implementers can play games, since the RM does not define the source representation. Just because your editor and operating system think it's a form-feed, doesn't mean your compiler does, and vice-versa. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Form feed comment for pragma Page 1996-06-04 0:00 ` Robert A Duff @ 1996-06-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 20+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) Bob said "Quite true, but implementers can play games, since the RM does not define the source representation. Just because your editor and operating system think it's a form-feed, doesn't mean your compiler does, and vice-versa. " Yes, I know these games well, but this particular one is unlikely, since the ACVC sources insist that form feed act as end of line (yes, yes, you could translate this to something else and still "mis- interpret form feed, but that is FAR out in the theoretical realm!) ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~1996-06-20 0:00 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-06-04 0:00 Form feed comment for pragma Page Rex Reges 1996-06-03 0:00 ` Robert Dewar 1996-06-06 0:00 ` Rex Reges 1996-06-05 0:00 ` Robert Dewar 1996-06-12 0:00 ` Rex Reges 1996-06-12 0:00 ` Rex Reges 1996-06-12 0:00 ` Robert Dewar 1996-06-13 0:00 ` Ken Garlington 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Arthur Evans Jr 1996-06-04 0:00 ` Robert Dewar 1996-06-06 0:00 ` Text_IO and Ada source (was: Form feed comment for pragma Page) Arthur Evans Jr 1996-06-06 0:00 ` Robert Dewar 1996-06-11 0:00 ` Norman H. Cohen 1996-06-12 0:00 ` Robert Dewar 1996-06-18 0:00 ` Norman H. Cohen 1996-06-20 0:00 ` Robert Dewar 1996-06-05 0:00 ` Form feed comment for pragma Page Keith Thompson 1996-06-04 0:00 ` Robert A Duff 1996-06-04 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox