Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!zaphod.mps.ohio-state.edu!ub!dsinc!netnews.upenn.edu!platypus!bill
From: bill@platypus.uofs.edu (Bill Gunshannon)
Newsgroups: comp.lang.c
Subject: Re: Wierd core dump on sparc-1
Message-ID: <246@platypus.uofs.edu>
Date: 28 Jan 91 22:03:47 GMT
References: <1991Jan24.061653.22785@tkou02.enet.dec.com> <14976@smoke.brl.mil>
Organization: University of Scranton, Scranton, PA
Lines: 22

In article <14976@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
> to a function.  Since SPARC tends to be less tolerant of such errors than
> some other C environments, it is possible that your code has such a problem.

Actually, I wouldn't lay the blame at the feet of SPARC.  I have a MIPS
that suffers the same problems.  And I have seen it in the past on 68K
systems with un-satisfactory memory management hardware.  It is a rather
wide spread problem.  I have reached the point where the first thing I
look for is an uninitialized string/char[] variable.

> Is "lint" happy with the code?

Unfortunately, passing "lint" doesn't guarantee that the hardware will
do what the compiler (or language) thinks is proper.

bill


-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank