copying zero characters
Richard Harter
If memcpy/memmove is given a value of zero for the number of
characters to be copied/moved is it guaranteed that nothing will
be done? The standard can be read that way but I'm checking.
Also does anyone know of an implementation where an argument of
zero might fail?
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Kafka wasn't an author;
Kafka was a prophet!
Francois Grieu
> If memcpy/memmove is given a value of zero for the number of
> characters to be copied/moved is it guaranteed that nothing will
> be done? The standard can be read that way but I'm checking.
The standard reads:
#include <string.h>
void *memcpy(void * restrict s1,
const void * restrict s2,
size_t n);
The memcpy function copies n characters from the object pointed
to by s2 into the object pointed to by s1.
IMHO it follows that when n is 0, no character is copied.
That is a pretty common assumption, and lots of code would
break if it did not.
I know several embedded environments with a memcpy-like
function which size argument is restricted to the range [1..256]
with 256 coded as 0, but I never met one with that memcpy-like
function named memcpy.
Fran�ois Grieu
Keith Thompson
> Richard Harter a écrit :
>> If memcpy/memmove is given a value of zero for the number of
>> characters to be copied/moved is it guaranteed that nothing will
>> be done? The standard can be read that way but I'm checking.
>
> The standard reads:
>
> #include <string.h>
> void *memcpy(void * restrict s1,
> const void * restrict s2,
> size_t n);
>
> The memcpy function copies n characters from the object pointed
> to by s2 into the object pointed to by s1.
>
> IMHO it follows that when n is 0, no character is copied.
Yes, but it does assume that s1 and s2 both point to objects.
> That is a pretty common assumption, and lots of code would
> break if it did not.
Certainly a memcpy that copied 1 byte given a third argument of 0
would break code. But I think the case being considered is:
memcpy(NULL, NULL, 0);
I believe the behavior of that call is undefined.
[snip]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard
> Francois Grieu <fgr...@gmail.com> writes:
>> Richard Harter a �crit :
>>> If memcpy/memmove is given a value of zero for the number of
>>> characters to be copied/moved is it guaranteed that nothing will
>>> be done? The standard can be read that way but I'm checking.
>>
>> The standard reads:
>>
>> #include <string.h>
>> void *memcpy(void * restrict s1,
>> const void * restrict s2,
>> size_t n);
>>
>> The memcpy function copies n characters from the object pointed
>> to by s2 into the object pointed to by s1.
>>
>> IMHO it follows that when n is 0, no character is copied.
>
> Yes, but it does assume that s1 and s2 both point to objects.
>
>> That is a pretty common assumption, and lots of code would
>> break if it did not.
>
> Certainly a memcpy that copied 1 byte given a third argument of 0
> would break code. But I think the case being considered is:
Why would you think that? His question was when the number to be moved
is 0. No other criteria.
>
> memcpy(NULL, NULL, 0);
>
> I believe the behavior of that call is undefined.
>
> [snip]
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
pete
> If memcpy/memmove is given a value of zero for the number of
> characters to be copied/moved is it guaranteed that nothing will
> be done?
If NULL is one of the other function call arguments
for memcpy/memmove, then you have undefined behavior
regardless of whether or not
0 is the last argument in your function call.
--
pete
Peter Nilsson
> Richard Harter a écrit :
>
> > If memcpy/memmove is given a value of zero for the number
> > of characters to be copied/moved is it guaranteed that
> > nothing will be done? The standard can be read that way
> > but I'm checking.
>
> The standard reads:
>
> #include <string.h>
> void *memcpy(void * restrict s1,
> const void * restrict s2,
> size_t n);
>
> The memcpy function copies n characters from the object
> pointed to by s2 into the object pointed to by s1.
>
> IMHO it follows that when n is 0, no character is copied.
That follows from 7.21.1p2 (n1336):
"Where an argument declared as size_t n 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."
--
Peter
Richard Harter
<ai...@acay.com.au> wrote:
>On Oct 14, 2:45=A0am, Francois Grieu <fgr...@gmail.com> wrote:
>> Richard Harter a =E9crit :
>>
>> > If memcpy/memmove is given a value of zero for the number
>> > of characters to be copied/moved is it guaranteed that
>> > nothing will be done? =A0The standard can be read that way
>> > but I'm checking.
>>
>> The standard reads:
>>
>> #include <string.h>
>> void *memcpy(void * restrict s1,
>> =A0 =A0 =A0const void * restrict s2,
>> =A0 =A0 =A0size_t n);
>>
>> The memcpy function copies n characters from the object
>> pointed to by s2 into the object pointed to by s1.
>>
>> IMHO it follows that when n is 0, no character is copied.
>
>That follows from 7.21.1p2 (n1336):
>
> "Where an argument declared as size_t n 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."
Thanks.
Tim Rentsch
> Francois Grieu <fgr...@gmail.com> writes:
>> Richard Harter a @C3{A9}crit :
>>> If memcpy/memmove is given a value of zero for the number of
>>> characters to be copied/moved is it guaranteed that nothing will
>>> be done? The standard can be read that way but I'm checking.
>>
>> The standard reads:
>>
>> #include <string.h>
>> void *memcpy(void * restrict s1,
>> const void * restrict s2,
>> size_t n);
>>
>> The memcpy function copies n characters from the object pointed
>> to by s2 into the object pointed to by s1.
>>
>> IMHO it follows that when n is 0, no character is copied.
>
> Yes, but it does assume that s1 and s2 both point to objects.
>
>> That is a pretty common assumption, and lots of code would
>> break if it did not.
>
> Certainly a memcpy that copied 1 byte given a third argument of 0
> would break code. But I think the case being considered is:
>
> memcpy(NULL, NULL, 0);
>
> I believe the behavior of that call is undefined.
Confirmed, supplying a null pointer (for either argument (and
also for memcpy)) is undefined behavior.
An argument could be made that the text of 7.1.4p1, which
specifies the default conditions for valid arguments, allows null
pointers when the value for 'n' is zero. (More specifically,
see the sentence starting "If a function argument is described
as being an array,".) However, such an argument is undercut
by 7.21.4.5p2, which illustrates needing to allow null pointers
explicitly when such values are to have defined behavior.