Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!zephyr.ens.tek.com!tekchips!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.modula2
Subject: Re: JPI V1.06b
Message-ID: <8243@tekgvs.LABS.TEK.COM>
Date: 9 Oct 90 15:08:28 GMT
References: <184.270F4253@puddle.fidonet.org>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 63

In article <184.270F4253@puddle.fidonet.org> Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) writes:
>Hello Tom:
>
>    What two bugs have you found in 1.06b that were present in 1.04?
>
(These bugs haven't been submitted to JPI, but I intend to do it now).

The first bug is related to JPI's decision to allow multiple memory models
like most C compilers. In the following program segment, no error is given
on the call to Str.Length even though (using small model) the type of the
actual and formal parameters don't match nor is code generated to properly
pass the argument by value (assuming it were possible). Even ANSI C compilers
don't screw this up; it is very unacceptable for a language like Modula-2.

FROM Lib IMPORT CommandLine;
FROM Str IMPORT Length;

...

slen := Str.Length(CommandLine^);

==========================================

I had been generating a "library" of object files, using a "Make" program and
the command line compiler interface. I do this because there are many files,
and there is no clean way to use the environment (I suppose a dummy program
that includes all the modules would do it, but I don't consider that very
clean).

At any rate, when I specify processor options (80386, 80387 in my case) these
options get included in the .obj file. When I compile my applications with
the same options, the environment compiler does not insert these options in
the .obj. The built-in make notices the discrepancy and forces recompilation
of all the library files. A needless operation, and one that generates
duplicate files since the new .obj's are placed in the current directory
rather than that of the library obj's.

================================================

I found a third bug, which probably existed in the 1.04 version as well.

I wanted to be able to redirect standard input from the command line (using 
the "<" operator). Using the IO.Rdxxx procedures no indication is produced
at end of file, therefor while redirection works, programs tend to hang if
they intend to continue reading until end of file.

I attempted to get around the problem by using FIO.Rdxxx(StandardInput,...)
which works fine reading from the keyboard (even EOF is indicated correctly)
but when input is redirected always returns an EOF state. A casual inspection
of the library source yielded no clues.

===============================================

One irritant, especially with the C compatibility. You can turn on or off
the capture of Control-Break, but you can't handle the interrupt with your
own routine. An inspection of the library sources shows code to handle C
style signals, but the capability is not passed to Modula-2. I'd like to be
able to capture all errors to recover myself, and then not generate that
error file.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply