| BITNET mail follows [message #268841] |
Thu, 27 February 1986 09:24 |
|
|
Originally posted by: TETHER
<pre>
Article-I.D.: ucbvax.8602271424.AA07242
Posted: Thu Feb 27 09:24:47 1986
Date-Received: Sat, 1-Mar-86 17:28:39 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 102
------------------------------------------------------------ ------
(* I posted this message last Sunday to INFO-ATARI instead of to *)
(* INFO-ATARI16. My apologies to those who must read it again. *)
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)
</pre>
|
|
|
|
Members
Search
Help
Register
Login
Home
