Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: Changed /usr/include/string.h for the DN400 machine under SR10.2
Message-ID: <1990Oct10.213555.8189@alchemy.chem.utoronto.ca>
Keywords: string.h, DN400, SR10.2
Organization: University of Toronto Chemistry Department
References: <7361@cae780.UUCP> <4d4d590d.20b6d@apollo.HP.COM>
Date: Wed, 10 Oct 90 21:35:55 GMT

In article <4d4d590d.20b6d@apollo.HP.COM> vasta@apollo.HP.COM (John Vasta) writes:
>In article <7361@cae780.UUCP> kv@csi.com (Kumar Venkatramani) writes:
>>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 ) 
>
>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.

The prototypes for 'strncpy' and 'strncat' are also missing (they are
spelled 'strcpyn' and 'strcatn' on the SR10.2 Apollo systems). This may be
bad news since these functions return "char *", not int; the proper
type will not be used since the proper prototype doesn't exist.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775