The invention of this noob tool

>>106149214 (OP)
Skill issue linked to wrong race.

>>106149214 (OP)
True memory copy should be done using language constructs-

>>106149240
If you have to copy memory, your software is already curry shitfest that I don't ever want to touch.

>>106149337
post code faggot

>>106149363
Fuck off tranny, why don't you invent something for once without copying others? Oh no, would that make you realize that you're a low IQ faggot who's not all that intelligent if you tried to do that? Awww, are you gonna cry and piss and shit yourself now? Thought so you spastic faggot.

>>106149214 (OP)
the problem with it is not that it's a "noob tool", but rather the fact that it was "noob-proofed" by being implemented as a memmove().. sometimes.. on some platforms.. in some implementations.. in some architectures.
it's is this kind of mix of under-specification, and randomly chosen implementation-specific behavio(|u)r that caused a lot of bugs to show up.. some of the time.. in some......
but there are no real coders. so i will leave this thread to continue to shit itself with nocoder talk, including from yourself.

>>106149447
>nocodeshitter
i expected that

>>106149447
>current year
>rustrannies still haven't written a single piece of original code
Those guys are just as pathetic as jeets

>>106149543
>>106149522
Go ask a LLM to vomit some free code for you, that's the only thing you deserve, H1B faggot.

>>106149551
>still no code
why do you make threads if youre so retarded you cannot project yourself 5 mins into the future
why do you talk about programming when youre a nocodeshitter?

are you trolling?

>>106149583
LLM will write as much free code as you want. Quality might match the price, but you weren't planning to pay me, were you?

>>106149602
>dances around the issue
ok, youre a nocodeshitter talking out of your ass

What? What's wrong with memcpy now? Performance? Safety? What the fuck is the point this shitty thread is trying to make ?

>>106149447
Also this is quite a retarded post. If you actually invented anything, or have immersed yourself in the works of someone who seemingly invents things, you'd know basically everything is always derivative, and incremental improvement or a remix of existing inventions.
OP must be like a 16 year old faggot or something.

>>106150081
i'm not sure myself there are two faggots bickering about god knows what not realizing software couldn't even exist without copying memory

>>106150225
Yes, I didn't invent a computer, but at least my code isn't as shit as yours, go fuck yourself, moron.

>>106149496
nobody has ever implemented memcpy as memmove. What might vary between implementations is the size of the chunks that get moved at once, whether it moves bytes at a time, words, dwords, etc. But only a retard would depend on an implementation detail at that level, they can't blame the implementation for their fuck up.

>>106149240
memcpy, in the way it's implemented does a lot of things. On most modern OS, it will copy pages using CoW which will reduce memory usage and prevent useless copy if you didn't plan to modify the copied data anyway, though that only applies for large chunks.

Also there's a benefit of having memcpy as a library feature instead of as a language construct. Say you have a compiled program for bare minimum x86 cpu. Then at runtime the memcpy implementation may choose a more suited alternative targeted for your specific instruction set. Windows has a feature to dynamically choose which function you want to use for each symbol. Elf does something similar with IFUNC

extern void memcpy(unsigned *data, size_t len);

void memcpy_c(unsigned *data, size_t len) { /* ... */ }
void memcpy_sse42(unsigned *data, size_t len) { /* ... */ }
void memcpy_avx2(unsigned *data, size_t len) { /* ... */ }

extern int cpu_has_sse42(void);
extern int cpu_has_avx2(void);

void memcpy(unsigned *data, size_t len) __attribute__((ifunc ("resolve_memcpy")));

static void *resolve_memcpy(void)
{
if (cpu_has_avx2())
return memcpy_avx2;
else if (cpu_has_sse42());
return memcpy_sse42;
else
return memcpy_c;
}

>>106150519
wrong on all accounts. and even if you're a nocoder (which is the case obviously), you would have known that you're wrong if you bothered with a little bit of searching. if you did, you would have found THOUSANDS of related search results. Here is one sample:
https://lwn.net/Articles/414467/
hell, you only had to be an average user from the era where libflashplayer.so had to be binary patched replacing memcpy() with memmove() to have heard about this.
but you are the typical zoom zoom kido nocoder with the typical "just don't write bad code" and "real programmers(TM) would never do this" nocoder retarded insights.

wtf does this even mean

>>106149214 (OP)
It should just be assignment and the actual code is generated by the compiler for the specific type.

>>106150081
Some retard seems to think it is possible to never copy memory in at least the large majority of code. I'm guessing that he's having a bad trip as a result of too much meth and acid.
OP is deranged. News at 11.

std::copy if you aren't unemployed

>>106149225
fpbp

>>106150519
lol
lmao even

>>106150433
Only due to the trivial case (you've never written any)

>>106154126
you have an impressive amount of confidence for someone who has no cue what he's talking about
>libflashplayer.so had to be binary patched replacing memcpy() with memmove()
I'll spoonfeed you: fixing something by replacing memcpy with memmove does not mean that the original memcpy implementation was a memmove. As I said, it definitely wasn't because that would be retarded

>>106149214 (OP)
Easily the best thing about C. Other languages can only cope.

>>106149337
>t. confirmed nocoder (and very unaccomplished bait poster)

>>106158097
Name 10 C++ codebases that aren't absolute dogshit.

>>106154126
>>106158319
Schizo samefag.

>>106154126
They didn't patch it by modifying the binary.
ELF, has a feature called IFUNC where you can customize the resolution logic for the runtime linker. I explained it in this post >>106152269

They patched glibc instead, any program that was made for glibc < 2.14 will have it's memcpy resolve to memmove. The reason is that developers copied overlapping buffers which is incorrect since memcpy expects restrict parameters, however due to the implementation of memcpy at the time, it created no issue. However, with modern memcpy implementations copying large chunks at a time, the source and dest must absolutely not overlap.

Here's what memcpy's man says:
In glibc 2.14, a versioned symbol was added
so that old binaries (i.e., those linked against glibc versions
earlier than 2.14) employed a memcpy() implementation that safely
handles the overlapping buffers case (by providing an "older"
memcpy() implementation that was aliased to memmove(3)).

>>106149214 (OP)
>memcopey
It's in the name

>>106149214 (OP)
>mov edi, <dest>
>mov esi, <src>
>mov ecx, <n>
>rep mov[sb]

>>106149225
fpbp