In C and C++, is it undefined behavior to memcpy into a const variable when the number of bytes to be copied is zero?
int x = 0;
const int foo = 0;
memcpy( (void *)&foo, &x, 0 );
This question is not purely theoretical. I have a scenario in which memcpy is called and if the destination pointer points to const memory, then the size argument is guaranteed to be zero. So I'm wondering whether I need to handle it as a special case.
The older question Is it guaranteed to be safe to perform memcpy(0,0,0)? points out 7.1.4p1:
Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.
The prototype for memcpy is
void *memcpy(void * restrict s1, const void * restrict s2, size_t n);
where the first parameter is not const-qualified, and &foo points to non-modifiable storage. So this code is UB unless the description of memcpy explicitly states otherwise, which it does not. It merely says:
The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1.
This implies that memcpy with a count of 0 does not copy any characters (which is also confirmed by 7.24.1p2 "copies zero characters", thanks Lundin), but it does not exempt you from the requirement to pass valid arguments.
memcpy(NULL, NULL, 0); not work. Requiring the argument to be readable (let alone writable) on zero bytes is a perverse reading of the standard. –
Whitechapel memcpy(0,0,0) would be genuinely more useful for some task than one that would treat it as a no-op, I think the Standard would be intended to allow such treatment. If there is no case where such treatment would be useful, then nobody should have any reason to care about whether the Standard would allow such treatment, and thus there would be no reason for the Standard to spend ink forbidding it. –
Levins if (size) memcpy(dest, src, size); by calling an external library function can't omit the if, but of course the function will have to do its own size==0 check in addition to the one performed by the calling code. One of the design principles behind C was that if on some platform no machine code would be necessary to ensure acceptable behavior in some case, neither the programmer nor compiler should have to write code to handle that case. –
Levins memmove and thus eliminates any redundant checks. "Expect" as in "file a bug report if it doesn't" –
Ugaritic memcpy or memmove will be so much greater than that of an optimized one that the former would only be faster when copying fewer than about 16 bytes. A well-designed C implementation should have multiple different library functions which would be employed in different scenarios (e.g. where the destination is known to be word-aligned but the source isn't, and the size is known to be a multiple of 4), but neither clang nor gcc is designed to accommodate such things. –
Levins memmove itself to be inlined, so your "n<16" check can be optimized for the many cases where that size is some sizeof Foo. –
Ugaritic &someStackObject for instance, where the optimizer knows it's aligned and can reasonably guess the object is in L1 cache. –
Ugaritic memmove. –
Levins p or p+1 is misaligned, if not both. And the function is basically a special case of memmove. Experimenting a bit more, GCC is the exception. It also calls memmove on ARM. MSVC and clang inline the code for x64 and ARM, and ICC inlines it too. –
Ugaritic memmove function. If gcc had come with a multiple-entry library function like memcpyup8: ldr r2,[r0,#0] / str r2,[r1,#0] / memcpyup7: ldr r2,[r0,#1] / str r2,[r0,#1] / ..., calling one of its entry points could offer better performance than using a loop, and be more compact in cases where one funciton could be called from multiple places in the program, but... –
Levins memcpy call. –
Levins It's clear that on the vast majority of platforms, an implementation which would process memcpy(anything, anything, 0) as a no-op, regardless of the validity of the source and destination pointers, would be in every way, in essentially every non-contrived scenario, as good or better than one that does anything else.
The way the Standard is written, however, could be interpreted as specifying that compilers are allowed to treat as UB any situation where the destination address is not associated with writable storage.
If one is using an implementation that seeks to process corner cases applying the philosophy documented in the Rationale document published by the authors of the Standard, without regard for whether the Standard unambiguously mandates such behavior, all memcpy and memmove operations where the size is zero will be reliably processed as no-ops. If the size will often be zero, there may be performance advantages to skipping a memcpy or memmove call in the zero-size case, but such a check would never be required for correctness.
If, however, one wishes to ensure reliable compatibility with compiler configurations that aggressively assumes that code will never receive inputs that trigger corner cases that aren't 100% unambiguously mandated by the Standard, and is designed to generate nonsensical code if such inputs are received, then it will be necessary to add a size==0 check in any case where a zero size might be accompanied by anything other than a pointer to writable storage, recognizing that such a check may negatively affect performance in situations where the size is very seldom zero.
-fno-strict-aliasing, -fno-delete-null-pointer-checks, and -fno-strict-overflow. Meaning that Linux kernel relies on a particular compiler's behavior in case of UB (e.g. that code like if (i+1 > i) if i is signed integer is NOT folded to if (1)). Perhaps the Linux kernel code can be changed/revised/fixed, so these no- can be removed leading to perf. increase. –
Disentitle (x+y)>y to be replaced with x>0, could be more efficient than code which rigidly defines behavior in all such cases. There is a huge difference between that, however, and the kinds of optimizations gcc performs around integer overflow, allowing even something as benign as uint1 = (ushort1*ushort2) & 0xFFFF; to arbitrarily corrupt memory if ushort1 exceeds INT_MAX/ushort2. –
Levins unsigned test(unsigned x) { unsigned i=1; while((i & 255) != x) i*=3; if (x < 256) arr[x] = 1; return i; }, then in situations where the return value is unused the store to arr[x] will be performed unconditionally. If the Standard were written in a way that could accommodate behavior inconsistent with sequential programmer execution without defenestrating all requirements, then a good abstraction model would allow x < 256 to be replaced with ((i & 255)==x) && (x < 256), which could... –
Levins ((i & 255)==x), and that could in turn be consolidated with the previous check of that condition in the loop if such check were actually performed, but such consolidation should cause the check outside the loop to be replaced with with an artificial data dependency on the computation of (i & 255) == x within the loop, rather than being dropped altogether. This should in turn preclude the elimination of the loop [unless a compiler recognizes that it would be more efficient to drop the loop and retain the post-loop comparison than vice versa. –
Levins xxx is printed. However, per ICC xxx is printed. Can a conforming C11 compiler eliminate infinite recursion per C11 5.1.2.3/4? –
Disentitle xxx if just the right amount of memory happened to be available when the program launched, and the code for main() happened to get placed in memory before the code for f(), such that the stack frames that were generated for callingf() happened to overwrite the code for f() with machine instructions to jump to a spot in main() just past the call to f(). The way the Standard is written, there are very few circumstances where anything an otherwise-conforming implementation might do... –
Levins #error directives or source programs that exercise at least one translation limit given in N1570 5.2.4.1. Since the program you linked does neither of those things, an implementation that output at least one diagnostic need not meet any other requirements. –
Levins © 2022 - 2024 — McMap. All rights reserved.
constmemory, then it is an invalid pointer and the behaviour is undefined according to cppreference. – Statuesque0bytes, then you are not writing to protected memory. You are not writing anything. – Lengthenconstpointer. It's about passing a pointer that was originallyconstwhen there is nothing to copy anyway. – Lengthenconstvariable, as the question makes quite clear.memset()won't do anything. It won't dereference anything, or attempt to write anywhere. – Lengthenifstatement that checks the number of bytes to copy and calling memcpy only if it is not 0. I would expect modern C++ compilers to compile the whole thing away, making the whole thing a moot point without any worries of whether this is undefined behavior, or not. – Rigmemcpythat make some things surprisingly undefined behavior. For examplememcpy( NULL, NULL, 0 )is technically undefined behavior because the pointers passed in must be valid, even though no copy is actually occurring. As for my original question, I couldn't find anything in the standard covering this exact scenario, though there may be something in there. – Silkweedmemcpy, so it's not unreasonable to see it in C++ code. – Ideomotorconstmemory or non-zero if it points to writable memory. So it's doubtful that the compiler will simply omit the call altogether, as it would in my trivial example. – Silkweedstd::bit_casttake care of most or all of those situations? – MagnetizeZeroCountCheckedMemcpywoud have defined behavior in that case butmemcpywould not, omitting the check could adversely affect the behavior of what should be a Strictly Conforming C Program. – Levins