Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ptsfa!pacbell!att-ih!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.windows.news
Subject: Re: NeWS on a SUN, bug in translate?
Message-ID: <1419@vaxb.calgary.UUCP>
Date: 1 Mar 88 23:00:18 GMT
References: <539@modular.UUCP> <2090@natmlab.dms.oz> <1369@vaxb.calgary.UUCP> <11843@sgi.SGI.COM>
Distribution: comp
Organization: U. of Calgary, Calgary, Ab.
Lines: 52
Keywords: NeWS

In article <11843@sgi.SGI.COM>, msc@ramoth.SGI.COM (Mark Callow) writes:
> In article <1399@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford Neal) writes:

> > If the C routines were intended as
> > a "porting aid", surely it is crucial that they perform all the required
> > functions, albeit slowly. This way, the person rewriting them in 
> > assembler for their machine will actually know what they are supposed
> > to do... 

> ... If I remember right the porting
> guide says this and also warns that they don't check for overflow.
> They serve as a means to get NeWS up quickly and that is all.  I was
> never in any doubt that they didn't check overflows and I also never
> had any trouble understanding what they were supposed to do.

My copy of the porting guide says nothing about this. I discovered the
problem when my test program failed in windows larger than about an
inch on a side. From there it took about two or three hours to track 
down the difficulty. I think this is doing quite well; I can easily
imagine someone taking days to find the problem.

> The function of the routines is obvious from the function names: frmul,
> vfrmul, frdiv, vfrdiv etc.  The algorithms used are not so obvious but 
> there *are* some helpful comments in fract.c especially in frmul.

Nothing in that module indicates that overflow checking was omitted. Nothing
indicates how overflows should be reported if they are checked for. The
comments in frmul don't say anything that everyone doesn't already know.
I figured out how to report overflows by looking at the PostScript 
interpreter and the 68000 version of the fract routines (which do check).
It then took me about a half hour to add the overflow checks.

> As I said in my article there are plenty of places that don't check the
> overflow flag so even when the fract routines are doing the right thing
> you aren't out of trouble.

I'm not sure what you mean to imply by this comment. Are you saying that
SUN was right not to bother with overflow checking in fract.c? The fact
that there are problems elsewhere in the code doesn't seem to me to be
a justification.

I am puzzled by the tone of this discussion. I think it is only reasonable
for customers to bitch a bit when software is written poorly. After all,
this problem took up several hours of my time, but took me only half an hour
to fix myself, once the problem was understood. Wouldn't it have been better 
if SUN had taken the extra half hour?

Now, I understand that the people working on NeWS are under pressure to
get the product out the door. There's obviously a tradeoff between 
quality and release date. I just don't think leaving the overflow checks out
of fract.c is a good tradeoff.

   Radford Neal