memcpy

Some people seem to think that C's strcpy() function is bad or evil. While I admit that it's usually better to use strncpy() in order to avoid buffer overflows, the following (an implementation of the strdup() function for those not lucky enough to have it) safely uses strcpy() and should never overflow: char *strdup(const char *s1) { char *s2 = malloc(strlen(s1)+1); if(s2 == NULL) { return NULL; } strcpy(s2, s1); return s2; } *s2 is guaranteed to have enough space to store *s1 , and using strcpy() saves us from having to store the strlen() result in another function to use later as the

After reading the following about memcpy() , I proceeded to read about memmove() : To avoid overflows, the size of the arrays pointed by both the destination and source parameters, shall be at least num bytes, and should not overlap (for overlapping memory blocks, memmove is a safer approach). (LINK) And after checking the program used to illustrate the working of memmove() I decided to tweak it by using memcpy() instead to see how different is the output.To my surprise,they are the same even if it's a case of overlapping memory blocks.Here is the program and the output,and I have proceeded to

I wrote the following code: #include <iostream> #include <string> #include <cstring> struct bar { std::string s3; std::string s4; }Bar; union foo { char * s1; char * s2; bar b1; foo(){}; ~foo(){}; }Foo; int main () { foo f1; bar b2; std::string temp("s3"); b2.s3 = temp; b2.s4 = temp; //f1.b1 = b2; //-- This Fails (Seg faults) /* #0 0x00002b9fede74d25 in std::string::_Rep::_M_dispose(std::allocator<char> const&) [clone .part.12] () from /usr/local/lib64/libstdc++.so.6 #1 0x00002b9fede75f09 in std::string::assign(std::string const&) () from /usr/local/lib64/libstdc++.so.6 #2 0x0000000000400ed1

Is using an uninitialized variable as the src for memcpy undefined behaviour in C? void foo(int *to) { int from; memcpy(to, &from, sizeof(from)); } Shafik Yaghmour The C committee proposed response to defect report 451: instability of uninitialized automatic variables is: The answer to question 3 is that library functions will exhibit undefined behavior when used on indeterminate values. The question in the defect had sought an exemption for memcpy and fwrite if this was indeed the case saying: [...] The fact that one wants to be able to copy uninitialized padding bytes in structs using memcpy

I was looking the implementation of memcpy.c, I found a different memcpy code. I couldnt understand why do they do (((ADDRESS) s) | ((ADDRESS) d) | c) & (sizeof(UINT) - 1) #if !defined(__MACHDEP_MEMFUNC) #ifdef _MSC_VER #pragma function(memcpy) #undef __MEMFUNC_ARE_INLINED #endif #if !defined(__MEMFUNC_ARE_INLINED) /* Copy C bytes from S to D. * Only works if non-overlapping, or if D < S. */ EXTERN_C void * __cdecl memcpy(void *d, const void *s, size_t c) { if ((((ADDRESS) s) | ((ADDRESS) d) | c) & (sizeof(UINT) - 1)) { BYTE *pS = (BYTE *) s; BYTE *pD = (BYTE *) d; BYTE *pE = (BYTE *) ((