Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 04 Sep 2024 09:07:20 -0700
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <86seufo11j.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me> <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org> <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com> <vb7ank$3d0c5$1@dont-email.me> <20240903190928.00002f92@yahoo.com> <vb7idh$3e2af$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 04 Sep 2024 18:07:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="24eb7fe042a4b91b667bdd96799998d3";
	logging-data="4096705"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+9L02T5UAA9j3pEb7yVfPt8c6KXN8CPDY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:WGo2sKhX8IOo2IXUlO9bXHT1sSQ=
	sha1:wehtp/6o+mlQcLh5Ox80RCzFQmU=
Bytes: 2956

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Michael S wrote:
>
>> On Tue, 3 Sep 2024 17:41:40 +0200
>> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>>
>>> Michael S wrote:
>>>
>>>> 3 years ago Terje Mathisen wrote that many years ago he read that
>>>> behaviour of memcpy() with overlappped src/dst was defined.
>>>> https://groups.google.com/g/comp.arch/c/rSk8c7Urd_Y/m/ZWEG5V1KAQAJ
>>>> Mitch Alsup answered "That was true in 1983".
>>>> So, two people of different age living in different parts of the
>>>> world are telling the same story.  May be, there exist old popular
>>>> book that said that it was defined?
>>>>    >>
>>>
>>> It probably wasn't written in the official C standard, which I
>>> couldn't have afforded to buy/read, but in a compiler runtime doc?
>>>
>>> Specifying that it would always copy from beginning to end of the
>>> source buffer, in increasing address order meant that it was
>>> guaranteed safe when used to compact buffers.
>>
>> What is "compact buffers" ?
>
> Assume a buffer consisting of records of some type, some of them
> marked as deleted.  Iterating over them while removing the gaps means
> that you are always copying to a destination lower in memory, right?

If all the records are in one large array, there is a simple
test to see if memcpy() must work or whether some alternative
should be used instead.