Path: ...!news.mixmin.net!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: Thu, 5 Sep 2024 15:48:37 +0200
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <vbccrl$bd22$5@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Sep 2024 15:48:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="622309b8b3e203ac6e38dece30d12fb2";
	logging-data="373826"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19PLjp8mVfRMmuYM5vu7kN7IdF2cG/w1BQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:VFpHwDjxCn0EgPSzRFUicOzPdSI=
Content-Language: en-GB
In-Reply-To: <1246395e530759ac79805e45b3830d8f@www.novabbs.org>
Bytes: 3127

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.