Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Frustrated trying to be portable
Message-ID: <15367@smoke.brl.mil>
Date: 3 Mar 91 04:18:48 GMT
References: <1991Feb20.175318.28496@zoo.toronto.edu> <2960@cirrusl.UUCP> <N4Q94O2@xds13.ferranti.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16

In article <N4Q94O2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
-In article <2960@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
-> [You can't implement it portably].  My portable solution, is to assume that
-> the caller of memmove() always knows the direction of the move.
-Are you sure? Either one of two situations exists:
-	The pointers are into the same object.
-	The pointers are into different objects.
-In the former case, overlap is a problem but you can compare them for
-magnitude. In the latter case, overlap is not a problem. The result of
-comparing two pointers into different objects is undefined but when you
-don't care about the result why worry?

Because any reliance on undefined behavior is obviously not portable,
as the man said.  In fact for a wide class of architectures, there is
no problem, but for some architectures the C run-time implementation
may trap on an attempt to compare two pointers to different objects.