Skip site navigation (1) Skip section navigation (2)

Re: fix memcpy() overlap

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fix memcpy() overlap
Date: 2004-02-03 04:26:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Mon, 2 Feb 2004, Tom Lane wrote:
>> This isn't a bug, and I see no reason to clutter the code just to shut
>> up valgrind.

> Isn't memcpy on overlapping (even entirely overlapping) buffers undefined
> behavior unless the count is 0?

The reason that the spec describes overlapped memcpy as undefined is
that it does not want to restrict which direction the copy occurs in
(proceeding from lower to higher memory addresses or vice versa).
memmove is constrained to do the copy in the direction that will avoid
failure when the source and destination partially overlap.  But memcpy
is expected to do whichever is fastest on the particular architecture,
without concern for possible overlap.  (Offhand I've never heard of a
machine where memcpy doesn't work lower-to-higher, but maybe there is

However, when the source and destination buffers are the same, it does
not matter which direction you copy in; you are picking up and putting
down the same bytes at the same addresses no matter what order you
process the bytes in.  There is no implementation in existence that will
produce an unwanted result.

If you want to argue about dependencies on implementation details that
are theoretically undefined according to the ANSI C spec, we have tons
more beyond this one.  F'r instance, depending on twos-complement
arithmetic is illegal per spec also ...

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-02-03 06:06:58
Subject: Re: [PATCHES] log session end - again
Previous:From: Tom LaneDate: 2004-02-03 03:31:40
Subject: Re: [PATCHES] log session end - again

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group