Sequent Dynix 4.4.2 problems with g++ compiler (w/fix suggested)

Ronald F. Guilmette rfg@monkeys.com
Tue Jan 25 12:38:00 GMT 2000


In message < 200001252004.MAA07068@kankakee.wrs.com >, you wrote:

>> To: bug-gnu-gcc@gnu.org, Jay Vosburgh <fubar@sequent.com>
>> Date: Mon, 24 Jan 2000 19:19:19 -0800
>> From: "Ronald F. Guilmette" <rfg@monkeys.com>
>
>> Unfortunately, whoever implemented the C library bcopy() function
>> for Dynix 4.4.2 didn't look closely enough at the original bcopy()
>> man page from BSD UNIX, and it appears the Dynix 4.4.2 bcopy() _does
>> not_ properly handle the case where the input and output regions
>> overlap.
>
>In that case, I would say arrange for libiberty to include bcopy
>through the normal magic, and then gcc will just use it.  Maybe an
>autoconf test that checks bcopy on the system to see if it `really'
>does work, and it it doesn't, pull it in.


Adding a configure-time test to see if bcopy ``really works'', even with
overlapping input and output regions, is probably a Good Idea.

However if it doesn't work, then there is no need for a replacement in
any GNU-specific file.  Rather, the existing #define:

   #  define bcopy(src,dst,len) memmove((dst),(src),(len))

in the system.h file should simply be activated.

Ideally, of course, all of these non-standard calls to the non-standard
bcopy() function should be ripped out of the compilers and replaced by
_standard_ calls to the _standard_ functions memcpy() and/or memmove()
buy hey!  That's likely to happen just about the time hell freezes over.
(I think that I suggested this change to Stallman about 10 years ago and
got nowhere.  Well, at least I tried.)

-- rfg

P.S.  Another simple solution:  Just have the system.h file _always_ provide
the #define shown above... except for those systems that DO NOT provide a
standard-conforming memmove() function.

My estimate of the number of such systems now in active use: 0

The original ANSI C standard (requiring memmove) came out in 1988.  It
seems that 12 years has been more than ample time for people to adapt
their libraries to its requirements.



More information about the Gcc-bugs mailing list