TETHER@HARVHEP.BITNET (02/24/86)
------------------------------------------------------------------ There are a number of bugs in the InOut module for TDI's Modula-2 compiler. I saw recently on info-atari that someone was having touble reading integers from a disk file. Here's why: Procedure Read does not convert CR-LF pairs to a single EOL character, but returns both characters individually. Procedure ReadString does not stop reading when it finds a trailing space, but goes up to the next control character. Since ReadCard and ReadInt use ReadString, if you try to read several integers or cardinals from a single line, you will get a runtime error (#9) because a string with embedded blanks is not valid for conversion to those types. Due to the bug in Read described above, ReadString will find a null string at the end of every line, sandwiched between the CR and LF. Procedure Read sets the Done flag to FALSE one character too soon. Upon returning from Read after reading the last character in a file, I find that Done = FALSE. That should be so only after a Read call made AFTER the last character has been input. Done is a signal that Read HAS failed, not that it WILL fail. Variable termCH is always set to 0C after a call to ReadString, ReadCard, or ReadInt. While it is true that 0C is used internally by TDI Modula-2 to terminate strings, termCH is supposed to be the character on the EXTERNAL medium that caused the procedure to stop reading, e.g., a space, a control character, or EOL. Procedure Write, when called with EOL as the argument, just writes the one character. Therefore, Write(EOL) is not equivalent to WriteLn, which writes CR-LF. The following, while not exactly bugs, I consider to be annoying mis-features: Although the OpenInput and OpenOutput procedures take a string argument called defext, it is ignored. I think that the argument is allowed only for compatibility with other implementations of Modula-2, but the manual doesn't say that. The screen is not placed in some standard state when a Modula-2 program starts. Therefore, where the first output appears depends upon where a previous program left off, which might be anywhere. I would like to have the screen cleared and the cursor homed automatically on start-up. There seems to be no simple way to do this myself without using VDI. A null string "" is allowed as an argument to a procedure that has a VAR ARRAY OF CHAR formal parameter, as is a string with multiple characters. A one-character string constant is not, being considered as type CHAR. Apparently this is due to the fact that open array parameters must be declared VAR, that type CHAR is not compatible with ARRAY OF CHAR but only assignment compatible, and that the types of arguments given for VAR parameters must be compatible with the type of the formal. Whew! Isn't this taking strict typing too far? I called the TDI offices in Dallas about the bugs, and will be sending them documentation sometime this week. I was told that it will probably be a couple of months before fixes are sent out, partly because all development work is done in England, partly because a new release of Modula-2 is planned for then anyway. To tide me over until then, I am going to write a new implementation module for for InOut. I will gladly share it with anyone who wants it, but I would like to make it as "standard" as possible. There are a few details of the implementation that Wirth does not make clear in "Programming in Modula-2" (second edition). Under what circumstances should ReadString return a null string? From Wirth's description, it seems that it returns a null string at the end of every line that has more than one trailing blank. That would be a nuisance if you're trying to read a text file word by word. Shouldn't leading tabs be skipped by ReadString as well as leading blanks? What provision is to be made for signalling end-of-file for terminal input? A program that tests the Done flag should be able to read from a terminal as well as from a disk file. Assuming that ReadCard and ReadInt use ReadString, what should they do if they read a null string: return zero, cause a run-time error, or keep reading (with a prompt for terminal input)? Let's have some discussion about this. After all, programs using InOut are supposed to be portable. Stephen Tether MIT Physics Dept. (UA1 group) SAT@MIT-MC (ARPANET) TETHER@MITLNS (BITNET)