Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!decwrl!cae780!kv
From: kv@cae780.UUCP (Kumar Venkatramani)
Newsgroups: comp.sys.apollo
Subject: Changed /usr/include/string.h for the DN400 machine under SR10.2
Keywords: string.h, DN400, SR10.2
Message-ID: <7361@cae780.UUCP>
Date: 4 Oct 90 19:01:19 GMT
Reply-To: kv@csi.com (Kumar Venkatramani)
Followup-To: comp.sys.apollo
Distribution: usa
Organization: Comdisco Systems Inc. Foster City, CA.
Lines: 31

I just recently went in to Qualify our software on the DN400 machine
running SR10.2 and saw something strange and wondered if anybody else
had run into it.

The file '/usr/include/string.h' is different on the DN400 than on the
other machines!!(even though both machines are running SR10.2). Ordinarily
I wouldn't have noticed but the new file causes memcpy() nad memcmp() to
be multiply defined and  a compile which used to work fails.  (The two
routines were defined in /usr/include/memory.h and continue to be defined
there ) 

The other thing I saw was that the 'C' compiler version 6.7 behaved 
differently in that in was more picky. It reported warnings when there
were characters after #endif, which does not occur on the 4500s or the 3500.

If anybody else has seen these differences, and is aware of workarounds
I would appreciate hearing from you..

As an aside, the 400 performed exceedingly well.  We have a benchmark
that is graphics intensive and memory intesive and the number for the 
400/Sparcstation 1+/4500 were are follows: 5.27/6.0/9.50.  I'm not
sure these numbers mean much, but the interactive performance is very good
compared to any other APOLLO boxes we have seen so far.

Thanks in advance for your response.

Kumar Venkatramani
Comdisco Systems Inc.
Foster City, CA 94404.
INTERNET ADD: kv@csi.com
UUCP     ADD: ..!uunet!cae780!kv