I am not so well-versed in the C standard, so please bear with me.
I would like to know if it is guaranteed, by the standard, that memcpy(0,0,0) is safe.
The only restriction I could find is that if the memory regions overlap, then the behavior is undefined...
But can we consider that the memory regions overlap here ?
I have a draft version of the C standard (ISO/IEC 9899:1999), and it has some fun things to say about that call. For starters, it mentions (§7.21.1/2) in regards to memcpy that
Where an argument declared as
size_tn specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function that compares two character sequences returns zero, and a function that copies characters copies zero characters.
The reference indicated here points to this:
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.
So it looks like according to the C spec, calling
memcpy(0, 0, 0)
results in undefined behavior, because null pointers are considered "invalid values."
That said, I would be utterly astonished if any actual implementation of memcpy broke if you did this, since most of the intuitive implementations I can think of would do nothing at all if you said to copy zero bytes.
memcpy. Silly me. I should have known better than to assume that programmers would repeat that kind of information for every single function description. –
Julienne realloc(0, 0). The use cases are similar, and I've used them both (see my comment under the question). It's pointless and unfortunate that the Standard makes this UB. –
Shelf abort and a nice backtrace. –
Descendent memcpy call) as the debug symbols have been stripped. And I don't really want to look at the assembly. –
Descendent memcpy doesn't come with it. Must be because nullpointers should be valid arguments to memcpy when the size argument is zero. –
Blinkers Just for fun, the release-notes for gcc-4.9 indicate that its optimizer makes use of these rules, and for example can remove the conditional in
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
return *src;
return 0;
}
which then gives unexpected results when copy(0,0,0) is called (see https://gcc.gnu.org/gcc-4.9/porting_to.html).
I am somewhat ambivalent about the gcc-4.9 behaviour; the behaviour might be standards compliant, but being able to call memmove(0,0,0) is sometimes a useful extension to those standards.
memcpy that doesn't exist in any implementation I know of, not to increase uniformity, but to deliberately break from it. –
Thorman memcpy as something like char *end=src+count;while(src<end){*dest++=*src++;} [saving the need to modify count during the loop]. Passing an invalid src pointer would trigger UB even if count is zero. –
Stingo count == 0. –
Thorman char *p = 0; int i=something;, evaluation of the expression (p+i) will yield Undefined Behavior even when i is zero. –
Stingo memcpy() should be allowed to perform any pointer arithmetic on its arguments prior to ensuring a non-zero count is another question [if I were designing the standards, I would probably specify that if p is null, p+0 could trap, but memcpy(p,p,0) would do nothing]. A much bigger problem, IMHO, is the open-endedness of most Undefined Behavior. While there are some things which really should represent Undefined Behavior (e.g. calling free(p)... –
Stingo p[0]=1;) there are a lot of things which should be specified as yielding indeterminate result (e.g. a relational comparison between unrelated pointers should not be specified as being consistent with any other comparison, but should be specified as yielding either a 0 or a 1), or should be specified as yielding a behavior slightly looser than implementation-defined (compilers should be required to document all possible consequences of e.g. integer overflow, but not specify which consequence would occur in any particular case). –
Stingo uint16_t foo=f(); int bar=0; if (foo > 50000) bar=3; if (foo*foo > 16383) bar |= 1;, what good can come from allowing 32-bit compiler to omit the first if? –
Stingo char *p; int flag;, what should char *q = p+123456789; int32_t d=q-p; if (flag) *q = 0; do if p is null and flag is zero? If non-zero? If the assignment to q asserts that p is non-null, then d can be assigned the literal 123456789, but there may not exist any trap pointer representation from which one could subtract a null pointer to yield 123456789. –
Stingo q trap, or overwriting memory location 123456789, I'd much prefer the former. Having arithmetic on a null-pointer value yield a null result might be an acceptable alternate behavior, but that would make the value of d dependent upon the value of p. –
Stingo NULL + foo is a valid pointer to such an extent that you want to ensure that it never is. Messing with null pointer arithmetic in the way you describe would ruin the identity p + (q-p) == q that I'd want to hold in any hypothetical safe dialect of C. –
Thorman *q=0; can be executed without trapping when q holds an invalid pointer, it will cause nasal demons. I would posit that the value of preventing *q=0; from causing nasal demons whenever possible outweighs the value of being able to perform arithmetic on null pointers without it trapping. It's virtually impossible for a practical C-standard-compliant platform to guard against absolutely all conceivable nasal demons, but stores to null-derived invalid pointers are both common and easy to check for. –
Stingo offsetof. Can you suggest any others? –
Stingo offsetof is one legitimate use. But I do not think that declaring things illegal in the absence of an argument for why they should be legal is sound language design policy. –
Thorman *++str, then you want to start with a one-before-the-beginning pointer. mmap likes to use (void *)-1 as an error return value. It just doesn't seem sensible to forbid computation of invalid pointers when they're never used to access memory. –
Thorman offsetof is implemented; an implementation where subtracting null from the address of a field of a null object happens to yield that field's offset may implement offsetof with such an expression, but an implementation would be free to implement it other ways. Although many implementations of C store pointers as linear memory addresses, nothing in the standard requires any such thing, and tricks such as you describe may fail on architectures which store pointers other ways [e.g. a system might store pointers using a pair of numbers, such that... –
Stingo p->q=123 is internally implemented as something analogous to memory_regions[p_base][p_ofs+offsetof(p.q)] = 123;; such a design would make it possible ensure that something like char *p=malloc(100); p[200]=0; will trap rather than overwriting some arbitrary object, and will allow the compiler to relocate malloc'ed memory regions if free space becomes fragmented, but may break if code tries to manipulate pointers in ways that assume a linear address space. –
Stingo intptr_t, performing the appropriate computations on the resulting value, and casting back. I would see great advantage to an extension to C which would specify p-q in three situations where it presently does not... –
Stingo p=realloc(q); p-q will hold an arbitrary non-zero value if the object was moved. –
Stingo == to be used (which should also be valid) but all three represent useful operations which are essentially impossible in purely-standard C. People trying to turn C into something it never was may howl at the idea of extending the set of formally-defined behaviors to include things that 99% of compilers supported anyway, but I hope those who want the language to be useful can get them anyway. –
Stingo You can also consider this usage of memmove seen in Git 2.14.x (Q3 2017)
See commit 168e635 (16 Jul 2017), and commit 1773664, commit f331ab9, commit 5783980 (15 Jul 2017) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 32f9025, 11 Aug 2017)
It uses an helper macro MOVE_ARRAY which calculates the size
based on the specified number of elements for us and supports NULL
pointers when that number is zero.
Raw memmove(3) calls with NULL can
cause the compiler to (over-eagerly) optimize out later NULL checks.
MOVE_ARRAYadds a safe and convenient helper for moving potentially overlapping ranges of array entries.
It infers the element size, multiplies automatically and safely to get the size in bytes, does a basic type safety check by comparing element sizes and unlikememmove(3)it supportsNULLpointers iff 0 elements are to be moved.
#define MOVE_ARRAY(dst, src, n) move_array((dst), (src), (n), sizeof(*(dst)) + \
BUILD_ASSERT_OR_ZERO(sizeof(*(dst)) == sizeof(*(src))))
static inline void move_array(void *dst, const void *src, size_t n, size_t size)
{
if (n)
memmove(dst, src, st_mult(size, n));
}
- memmove(dst, src, (n) * sizeof(*dst));
+ MOVE_ARRAY(dst, src, n);
It uses the macro BUILD_ASSERT_OR_ZERO which asserts a build-time dependency, as an expression (with @cond being the compile-time condition which must be true).
The compilation will fail if the condition isn't true, or can't be evaluated by the compiler.
#define BUILD_ASSERT_OR_ZERO(cond) \
(sizeof(char [1 - 2*!(cond)]) - 1)
Example:
#define foo_to_char(foo) \
((char *)(foo) \
+ BUILD_ASSERT_OR_ZERO(offsetof(struct foo, string) == 0))
As noted by user16217248 in the comments:
In C11 the
BUILD_ASSERT_OR_ZEROmacro is not necessary because we havestatic_assert()
BUILD_ASSERT_OR_ZERO macro is not necessary because we have static_assert() –
Beaty © 2022 - 2024 — McMap. All rights reserved.
memcpy. – Chiapasmemcpy(0,0,0)is one of the weirdest pieces of C code I've seen. – Selfemployedmemcpy(outp, inp, len)? And that this could occur in code whereoutpandinpare dynamically allocated and are initially0? This works, e.g., withp = realloc(p, len+n)whenpandlenare0. I myself have used such amemcpycall -- while it is technically UB, I've never encountered an implementation where it isn't a no-op and don't ever expect to. – Shelfmemcpy(0, 0, 0)is most likely intended to represent a dynamic, not static invocation ... i.e., those parameter values need not be literals. – Shelf