Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!osf.ORG!jeffc
From: jeffc@osf.ORG (Jeff Carter)
Newsgroups: comp.lang.icon
Subject: Porting Icon 7.5 to a new and Unique UNIX machine
Message-ID: <9533.636652949@soba>
Date: 5 Mar 90 16:02:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 47

I recently began porting (a reasonably simple task) Icon to a 
DECstation 3100 (MIPS RISC chipset, runs Ultrix. aka PMAX). I have run
in to a couple of things that hopefully someone else out there has a 
solution for, or suggestions how to debug:

(1) There are numurous calls to fopen() with "rb" and "wb" modes that
are _not_ surrounded by OS-specific #ifdef's. This leads me to believe
(unfortunately) that maybe the particular version I have hasn't been
run on a wide variety of UNIX machines. Any comments? Are other versions
of UNIX more forgiving than ULTRIX 3.0?

(2) Floating-point conversions. I get numerous failures of the "eval"
and "fncs" tests that seem to stem from a problem with the conversion of
real numbers to their string representations. For example, from the
"eval" test:

3c3
< 2.0 === +2.0 ----> 9.018482111602407e-O4
---
> 2.0 === +2.0 ----> 2.0

And from the "fncs" test:

3c3
< copy(1.0) ----> 9.017964046223754e-O4
---
> copy(1.0) ----> 1.0

There are numerous other examples, but almost all of the reported errors 
are similar to these.

(3) Memory allocation. Early the startup, the executable calls fopen() in 
order to get the code file. This, unfortunately, causes fopen() to call
malloc(), which immediately fails because initalloc() hasn't been 
called. And initalloc doesn't get called until after the header is read
from the code file. This forces me to use the static allocation versions
of the memory management routines. The first application that I want to use
this for wants to use a _lot_ of string space. I keep getting "out
of space in string region" errors, and having to restart with larger and
larger values. This is a royal pain. Has anyone looked at making the code
region be allocated out of the static memory region, or some other technique
that would let me initialize the memory allocation routine earlier? 
Is there a particular reason why this _won't_ work (so I don't waste my
time on it, only to dicover the fatal flaw.)

	jeff carter
	jeffc@osf.org