Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is memcpy with len=0 a NOP?

Reply
Thread Tools

Is memcpy with len=0 a NOP?

 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      01-28-2011
Noob wrote:
> Consider
>
> int i = 123;
> int j = 456;
> memcpy(&i, &j, 0);
>
> Is the call to memcpy with len==0 well-defined, and equivalent
> to a NOP, leaving the entire state machine unchanged?


In case of C99, the answer is clearly yes. 7.21.1p2 explicitly
addresses the case of n==0 for all <string.h> functions declared with a
`size_t n` parameter.
--
Marcin Grzegorczyk
 
Reply With Quote
 
 
 
 
Donkey Hottie
Guest
Posts: n/a
 
      02-01-2011
On 28.1.2011 20:05, Marcin Grzegorczyk wrote:
> Noob wrote:
>> Consider
>>
>> int i = 123;
>> int j = 456;
>> memcpy(&i, &j, 0);
>>
>> Is the call to memcpy with len==0 well-defined, and equivalent
>> to a NOP, leaving the entire state machine unchanged?

>
> In case of C99, the answer is clearly yes. 7.21.1p2 explicitly
> addresses the case of n==0 for all <string.h> functions declared with a
> `size_t n` parameter.


Why NOP?

If not

PUSH ...
PUSH ...
PUSH ...
CALL ...

whatever, but why NOP?

The compiler could just drop it.

--

You will obey or molten silver will be poured into your ears.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2011
Donkey Hottie <(E-Mail Removed)> writes:
> On 28.1.2011 20:05, Marcin Grzegorczyk wrote:
>> Noob wrote:
>>> Consider
>>>
>>> int i = 123;
>>> int j = 456;
>>> memcpy(&i, &j, 0);
>>>
>>> Is the call to memcpy with len==0 well-defined, and equivalent
>>> to a NOP, leaving the entire state machine unchanged?

>>
>> In case of C99, the answer is clearly yes. 7.21.1p2 explicitly
>> addresses the case of n==0 for all <string.h> functions declared with a
>> `size_t n` parameter.

>
> Why NOP?
>
> If not
>
> PUSH ...
> PUSH ...
> PUSH ...
> CALL ...
>
> whatever, but why NOP?


NOP in this context doesn't refer to a machine instruction of that
name. It just means "no operation". A call to memcpy() with 0 for the
third argument (and valid pointers for the first two) has no effect
(except possibly some amount of time).

> The compiler could just drop it.


That's exactly the point.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Francois Grieu
Guest
Posts: n/a
 
      02-02-2011
Le 27/01/2011 21:24, Jorgen Grahn a écrit :
> On Wed, 2011-01-26, Francois Grieu wrote:
>> On 24/01/2011 11:15, Noob wrote:
>>> Is the call to memcpy with len==0 well-defined, and equivalent
>>> to a NOP, leaving the entire state machine unchanged?

>>
>> I won't try to answer that based on the C standard,
>> but here is a recent (2009-2010) anecdote.
>>
>> I was developing for an STM7-based embedded system.
>> The recent, under-active-support C compiler had an
>> "intrinsic" memcpy that generated tight code when
>> the source and destination of memcpy were known at
>> link time and the length fitted a byte.
>> I found that hard way that this optimization was
>> broken: when the length had the value 0 and was not
>> a constant expression (e.g. was a byte variable),
>> 256 bytes got copied.

>
> Your compiler was broken.


Yes.

> With all due respect, I see no other lesson in that.


That compilers ARE broken in corner cases is a lesson.

> Surely lots of real-life code expects memcpy(foo, bar, n),
> with n evaluating to 0, to work as expected.


And I'll now write
if (n>0) memcpy(foo, bar, n)
when I want my code to run on more compilers.

Francois Grieu
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-02-2011
On Wed, 2011-02-02, Francois Grieu wrote:
> Le 27/01/2011 21:24, Jorgen Grahn a écrit :
>> On Wed, 2011-01-26, Francois Grieu wrote:
>>> On 24/01/2011 11:15, Noob wrote:
>>>> Is the call to memcpy with len==0 well-defined, and equivalent
>>>> to a NOP, leaving the entire state machine unchanged?
>>>
>>> I won't try to answer that based on the C standard,
>>> but here is a recent (2009-2010) anecdote.
>>>
>>> I was developing for an STM7-based embedded system.
>>> The recent, under-active-support C compiler had an
>>> "intrinsic" memcpy that generated tight code when
>>> the source and destination of memcpy were known at
>>> link time and the length fitted a byte.
>>> I found that hard way that this optimization was
>>> broken: when the length had the value 0 and was not
>>> a constant expression (e.g. was a byte variable),
>>> 256 bytes got copied.

>>
>> Your compiler was broken.

>
> Yes.
>
>> With all due respect, I see no other lesson in that.

>
> That compilers ARE broken in corner cases is a lesson.


Sure, I don't disagree with that -- except maybe that you classify
this as a corner case. There is no doubt that memcpy() with a zero
length should work, and that it's used in lots of real, working code.
Probably, your standard library uses it too.

>> Surely lots of real-life code expects memcpy(foo, bar, n),
>> with n evaluating to 0, to work as expected.

>
> And I'll now write
> if (n>0) memcpy(foo, bar, n)
> when I want my code to run on more compilers.


That will look very strange to your readers -- people who
don't use the broken compiler, or who read the code ten
years after the bug was fixed.

I think I would reason like this:
- Does the vendor seem responsive, e.g. promise a fix within
a week or so? A broken memcpy() is a serious fault.
YES => wait for the fix
NO => write a replacement implementation of memcpy, document
exactly why it's needed, and
#ifdef HAVE_COMPILER_BUG_4711
#define memcpy my_memcpy
#define bcopy ... etc if needed
#endif
Or disable the builtin memcpy(), if the compiler
supports that (gcc does that with -fno-builtins).
NO => Also make a plan for switching to a serious compiler
vendor, and plan for more problems like this one.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-02-2011
On 2/2/2011 5:53 AM, Francois Grieu wrote:
> [... concerning a broken memcpy() implementation ...]
>
> And I'll now write
> if (n>0) memcpy(foo, bar, n)
> when I want my code to run on more compilers.


I recall an implementation where `free(NULL)' was a rough
equivalent for `abort()', but I don't write `if (ptr) free(ptr);'
as a matter of routine; do you?

I recall an implementation whose strlen() was a performance
pig, but I do not write `ptr[0] ? strlen(ptr) : 0' as a matter
of routine; do you?

When it's a matter of getting around a bug in Frobozz Magic C
in the absence of a fix from Frobozz, I'll use whatever hack I
must (and so should you), but I don't think it makes sense to
adopt those hacks into your normal coding practices. Use the
hack when you must, but only when you must. Otherwise, you'll
spend your time writing fixes for bugs that don't even exist
(and you may well introduce new ones).

See also Jorgen Grahn's response.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Francois Grieu
Guest
Posts: n/a
 
      02-03-2011
On 03/02/2011 00:32, Eric Sosman wrote:
> On 2/2/2011 5:53 AM, Francois Grieu wrote:
>> [... concerning a broken memcpy() implementation ...]
>>
>> And I'll now write
>> if (n>0) memcpy(foo, bar, n)
>> when I want my code to run on more compilers.


Notice that I did not write: in all my code. I have a
category of programs/libraries that I want to be able to
hand to a customer/coworker, in source form, and be
reasonably sure that it will produce the right result
for them as supplied. That's when I go to such extremes.


> I recall an implementation where `free(NULL)' was a rough
> equivalent for `abort()', but I don't write `if (ptr) free(ptr);'
> as a matter of routine; do you?


I recall doing that a long time ago, but admittedly it was
because I did not yet know that free(NULL) should be OK.

> I recall an implementation whose strlen() was a performance
> pig, but I do not write `ptr[0] ? strlen(ptr) : 0' as a matter
> of routine; do you?


No. I typically maintain a variable with the current length of a
string, and sometime compute the string's length using my own
code, especially when it is the only dependency to <string.h>

> When it's a matter of getting around a bug in Frobozz Magic C
> in the absence of a fix from Frobozz, I'll use whatever hack I
> must (and so should you), but I don't think it makes sense to
> adopt those hacks into your normal coding practices. Use the
> hack when you must, but only when you must. Otherwise, you'll
> spend your time writing fixes for bugs that don't even exist
> (and you may well introduce new ones).


For code targetting a particular platform, I do just that,
including hiding the workaround as a macro and making it
conditional to compilation under FrobozzC, reporting the bug
with a smallish reproducible example, and when it is fixed
making the workaround specific to the broken version of
FrobozzC (or leaving it only in my compiler test suite).
In the last 3 years I reported 18 issues to tool vendor C
and 9 to tool vendor K.
That particular memcpy() issue was fixed less than 2 weeks
following my report, which mentioned I had a workaround.
For that other bug without a reasonable workaround, I got
4 hours turnaround time:

<OT>
] The statement
] j + 2;
] may be compiled to code that add 1 (rather than 2) to j, when
] the previous and next statement use the byte j.
]
] ; 50 if( j < 5 )
] ld a,_j
] cp a,#5
] jruge L13
] ; 52 j += 2; // compiler messes up here
] inc _j
] inc a
] ; 53 if( j < 5 )
] ld _j,a
] cp a,#5
]
] This occurs for many compiler settings, including the defaults
] for [my target].
</OT>

> See also Jorgen Grahn's response.


Yes. Again I often do just that.


Francois Grieu
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
memcpy for copying arrays franky.backeljauw@ua.ac.be C++ 13 09-17-2003 11:36 PM
Problem with malloc, realloc, _msize and memcpy Bren C++ 8 09-03-2003 11:01 PM
memcpy problem with padding for word alignment!!! very urgent Ninan Thomas C++ 3 08-22-2003 06:19 AM
Optimized memcpy to reduce cache misses John Edwards C++ 1 08-07-2003 03:01 AM
Re: Optimized memcpy to reduce cache misses David Bradley C++ 0 08-07-2003 12:39 AM



Advertisments