Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!apollo!vasta
From: vasta@apollo.HP.COM (John Vasta)
Newsgroups: comp.sys.apollo
Subject: Re: Changed /usr/include/string.h for the DN400 machine under SR10.2
Summary: sys5.3 versus bsd4.3, I think
Keywords: string.h, DN400, SR10.2
Message-ID: <4d4d590d.20b6d@apollo.HP.COM>
Date: 9 Oct 90 22:27:00 GMT
References: <7361@cae780.UUCP>
Sender: root@apollo.HP.COM
Reply-To: vasta@apollo.HP.COM (John Vasta)
Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA
Lines: 27

In article <7361@cae780.UUCP> kv@csi.com (Kumar Venkatramani) writes:
>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.

It sounds like you're observing some differences between the bsd4.3 and
sys5.3 environments. The sys5.3 version of string.h contains the memory
function declarations but the bsd4.3 version doesn't. Also, the sys5.3
cpp warns about tokens following #endif, but the bsd4.3 version doesn't.
Make sure you're in the environment you want to be when compiling your
program.

John Vasta                Hewlett-Packard Apollo Systems Division
vasta@apollo.hp.com       M.S. CHR-03-DW
(508) 256-6600 x5978      300 Apollo Drive, Chelmsford, MA 01824
UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta