Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Wierd core dump on sparc-1
Message-ID: <15009@smoke.brl.mil>
Date: 29 Jan 91 18:17:37 GMT
References: <1991Jan24.061653.22785@tkou02.enet.dec.com> <14976@smoke.brl.mil> <246@platypus.uofs.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 14

In article <246@platypus.uofs.edu> bill@platypus.uofs.edu (Bill Gunshannon) writes:
>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.

I wasn't "blaming" SPARC.  The point is that RISC architectures differ
sufficiently from VAX-like CICS architectures that bugs in C code may
not turn up on VAX-like architectures but are likely to show up when
porting to a RISC machine.  For example, AT&T's Documenter's WorkBench
Release 2.0 failed miserably on Pyramid processors, due to the programmer
having made certain assumptions about how arguments were passed to
functions (rather than using the varargs mechanism).