Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!ptsfa!ihnp4!cuae2!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.lang.c
Subject: Re: Trouble with Greenhill's C compiler
Message-ID: <1291@killer.UUCP>
Date: Wed, 5-Aug-87 17:29:49 EDT
Article-I.D.: killer.1291
Posted: Wed Aug  5 17:29:49 1987
Date-Received: Sat, 8-Aug-87 12:49:56 EDT
References: <1241@killer.UUCP> <1542@frog.UUCP>
Organization: Big "D" Home for Wayward Hackers
Lines: 30
Keywords: c optimizing bugs compiler greenhills
Summary: Problem solved.  I think ...

In article <1542@frog.UUCP>, john@frog.UUCP writes:
> In article <1241@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes:
> E> Question is: is there any kind of problem with Greenhills expecting
> D> some more normal pointer behavior?  I added fprintf's to help debug the
>  > code, and it only behaves when the fprintf's are in place.
> 
> However, if I were you, I would NOT, repeat ***NOT*** rule out
> "some simple problem with the code".  I have seen FAR too much code that
> compiled and ran fine on other systems that Greenhills gave wierd results
> for -- because the code really was WORNG!

The problem seems to be that the Ultrix compiler barfs on a cast that is
needed in this routine, so the cast was taken out shortly after the code
was written.  There seems to be a bug in the Ultrix compiler having to do
with casts.

The GH compiler barfs without the cast.  Why, who knows.

Since it ain't my code anymore I'm just going to leave the cast in and
not bother trying to figure out what is up with the compiler.

Note:  Why any of the other code isn't affected is beyond me.  You couldn't
get this program through lint if your life depended on it ...

- John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993