Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!ispi!jbayer
From: jbayer@ispi.UUCP (id for use with uunet/usenet)
Newsgroups: comp.unix.xenix
Subject: Re: Pascal Compiler for Xenix
Summary: some are bugs, some are features, some are bad docs, I have 3.32
Keywords: XENIX PASCAL COMPILER
Message-ID: <209@ispi.UUCP>
Date: 8 Oct 88 02:28:27 GMT
References: <1343@ndsuvax.UUCP> <194@ispi.UUCP> <912@stcns3.stc.oz>
Organization: Intelligent Software Products, Inc.
Lines: 96

In article <912@stcns3.stc.oz>, peter@stcns3.stc.oz (Peter Jeremy) writes:
> In article <194@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
> >In article <1343@ndsuvax.UUCP>, nenicola@ndsuvax.UUCP (Steven Nicolai) writes:
> >> I am looking for Pascal compilers for a xenix based system.
> >
> >Look at  the Microsoft Pascal compiler.  It is compatable at the source level
> >with the same compiler on dos.  It has both of the extensions you want (the
> >strings are called "lstring"s), and is fairly bug-free.  We have been using
> >both versions (DOS and Xenix) for a few years now with very few problems.
> 
> "Fairly bug-free" depends on your point of view.  I have had the unfortunate
> experience of having to port some Pascal to XENIX using this compiler and
> put simply, it stinks.  As does Microsoft's support for it (at least in Oz).
> 
> A quick overview of problems (from memory - I don't have all the bug info
> handy) - (This refers to version 3.30 of the compiler)
				   ^^^^
			I have been running the compiler version 3.32 for
a year or so, with no problems.

> 1) The installation procedure destroys the SCO C development system (by
>    altering a number of include file links so that they effectively #include
>    themselves). (Under Xenix 2.1.3 anyway - having been bit once, I re-installed
>    it manually when we upgraded to 2.2).

			It has been a while, but I do not recall this problem.
It is possible that it was masked by my other work.

> 2) The compiler leaves its temporary files lying around (with fixed file
>    names) in the current directory (not a major bug in itself, but can be
>    nasty in combination with the following).

	True.

> 3) When pass1 fails, pass2 will be invoked anyway - and then fail because it
>    can't find the temporary files it needs (assuming that they weren't left
>    over from a previous compilation).

	Not with 3.32

> 4) There are problems relating to the use of (global) user defined types
>    in local record descriptions - like the type goes away when the record
>    that used it does.

	This is a documentation problem.  The compiler works OK, but if you
are not careful with your scoping it will seem like a bug.

> 5) include files are supported, but cause random compiler core dumps - very
>    time-consuming to fix, because the only way to do it is by trial and error
>    (and my application had _lots_ of include files).

	Again, not with my experience with 3.32, and I have an application
which compiles and links to about 600k, and it also has _lots_ of include files

> 6) The use of the C procedure calling method (necessary to access OS
>    functions) interacts fatally with some debugging options.

		Please expand on this.

> 7) There appear to be bugs in the random-IO calls resulting in adjacent
>    records being munged (faulty seeking and block-buffering I think).

		I use my own file-io routines, so I never saw this.

> 8) Only large model is available, and the generated code is a lot poorer
>    than equivalent C code.

		True about the large model code, and how do you conclude that
the generated code is poorer?

> 9) The documentation for OS calls is in C and requires you to work out what
>    the equivalent Pascal declarations are.

		True.

> When I reported the bugs to Microsoft (in December 1986), I was sent a
> (beta?) copy of version 3.31.  This didn't fix any of the bugs that
> affected me, but did add a new one - the WRITE() procedure called the
> library procedure to _read_ the file rather than write it (I comfirmed
> this by studying the generated assembler).  When I reported this, I was
> thanked and told that they had no plans for correcting it in the near
> future.  (When I checked in Feb 88, I was told that no further work had
> been done, or was likely in the near future).
> 

		I can add one more problem to his list.  If you declare too
many variables, the compiler will get a stack overflow.

		I still stand by my previous statement.  Admittedly it is 
not the best, but with this compiler (and the DOS version) I am able to
maintain a large (>50,000 lines of code) program on both DOS and
Xenix without too many problems.  I have received version 4 of the DOS 
compiler, and have not yet been able to check it out.

Jonathan Bayer
Intelligent Software Products, Inc.