Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 6 Sep 2024 09:23:21 +0200
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vbeal9$nlm3$3@dont-email.me>
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> <86seufo11j.fsf@linuxsc.com>
 <vba6qa$3u4jc$1@dont-email.me>
 <1246395e530759ac79805e45b3830d8f@www.novabbs.org>
 <vbccrl$bd22$5@dont-email.me>
 <951f1cc96911357ff58bf27d62d9fc0e@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 06 Sep 2024 09:23:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6ee2407e3ebfa0481e4977a48a1e13c1";
	logging-data="775875"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+TgslO+poqB6/0OfMoIefe/uuO6XFmkf0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:qizBKIVrV7y4xGM4no6qMD/FZ/k=
In-Reply-To: <951f1cc96911357ff58bf27d62d9fc0e@www.novabbs.org>
Content-Language: en-GB
Bytes: 3608

On 05/09/2024 21:24, MitchAlsup1 wrote:
> On Thu, 5 Sep 2024 13:48:37 +0000, David Brown wrote:
> 
>> On 04/09/2024 20:13, MitchAlsup1 wrote:
>>> On Wed, 4 Sep 2024 17:53:13 +0000, David Brown wrote:
>>>
>>>> On 04/09/2024 18:07, Tim Rentsch wrote:
>>
>>>>> 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.
>>>>
>>>> Such tests are usually built into implementations of memmove(), which
>>>> will chose to run forwards or backwards as needed.  So you might as 
>>>> well
>>>> just call memmove() any time you are not sure memcpy() is safe and
>>>> appropriate.
>>>
>>> Memmove() is always appropriate unless you are doing something
>>> nefarious.
>>> So:
>>> # define memcpy memomve
>>> and move forward with life--for the 2 extra cycles memmove costs it
>>> saves everyone long term grief.
>>>
>>
>> Or just use memmove, and not memcpy, whenever you are moving stuff
>> around in the same buffer.
>>
>>> When you need the nefarious activities of memcpy write it as a
>>> for loop by yourself and comment the nafariousness of the use.
>>
>> memcpy is not nefarious.  It's quite simple, and does what it says on
>> the tin.  Use it when you want to copy non-overlapping memory areas.
>> Don't use it if you want to do something other than that.  I have never
>> understood why anyone would find this difficult.
> 
> There are compilers that:: s/memcpy/memmove/g

They can do that if they want - memcpy can be implemented using memmove, 
but not vice versa.

That doesn't mean it is at all a good idea to use memcpy when you mean 
memmove.