Pascal Compiler for Xenix
id for use with uunet/usenet
jbayer at ispi.UUCP
Sat Oct 8 12:28:27 AEST 1988
In article <912 at stcns3.stc.oz>, peter at stcns3.stc.oz (Peter Jeremy) writes:
> In article <194 at ispi.UUCP> jbayer at ispi.UUCP (id for use with uunet/usenet) writes:
> >In article <1343 at ndsuvax.UUCP>, nenicola at 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.
More information about the Comp.unix.xenix
mailing list