cancel
Showing results for 
Search instead for 
Did you mean: 

memmove problem

Dave Byrne
Member

memmove problem

I have a problem with memmove.  Although I've found a couple of workarounds the problem seems odd to me.  It is encapsulated in the following code.
 
 
#include <ansi_c.h>
int main (int argc, char *argv[])
{
 char * string[10] = {"a", "b", "c", "d", "e", "f", "g", "h", "i", "j"};
 char** source = string + 1;
 char** destination = string + 5;
 union {
  char ** c;
 }d;
 union {
  char ** c;
 }s;
 
 /*
 The following works.  Note that I've tried cast to a number of different types including (long **) all of which work.  In the orignal program, casting the parameters to what they are, (char **), also failed but appears to work in this stub.
 */
 memmove((void *)destination, (void *)source, 3 * sizeof(char*));
 
 /*
 This also works although why using unions should make a difference is a mystery to me.
 */
 s.c = source;
 d.c = destination;
 memmove(d.c, s.c, 3 * sizeof(char*));
 
 /*
However, the simple option that I tried originally generates a General Protection Fault.
 */
 memmove(destination, source, 3 * sizeof(char*));
 
 return 0;
}
8 REPLIES 8
msaxon
Active Participant

Re: memmove problem

You are trying to move (char)s, not (char *)s. So your declarations of  source and destination should be (char *), not (char **):

char* source = string + 1;
char* destination = string + 5;

and the memmove() should be:

memmove(destination, source, 3 * sizeof(char));
 

assuming you actually want to move 3 chars.

 

--
Martin
Certified CVI Developer
Dave Byrne
Member

Re: memmove problem

Martin,

I'm afraid that you have misunderstood.  I want to move char* not char.

 

Also. I forgot the important version info:

CVI: 8.0.1(356)

DAQmx: 8.3.1f0

I have observed the problem under both Windows 2000 and XP

jr_2005
Active Participant

Re: memmove problem

David,

Do you get the problem when you run a Release version of your code? I tried your simple example and reproduced the baffling behaviour (and GPF) within the CVI environment, but when I tried a standalone Release executable I did not get a GPF error. It just might be that the CVI debug environment is getting confused with this library call and is screwing up the stack somehow - I have a vague recollection that CVI debug puts all sorts of extra stuff around function calls and parameter lists.

I'm guessing that your real code is a bit more complex than the sample snippet you posted - can you tell if a release version works OK?

JR

Dave Byrne
Member

Re: memmove problem

JR,

I confess that I had not tried generating a release configuration.  However, you are correct, the full program works under such conditions.  In truth, the original post was merely aimed a NI to point out what appeared to be a compiler bug.  But you appear be right to narrow it down to the debug code.

Many thanks,

Dave

P.S. I need the code to work in the debugger and hence my chosen workaround is to cast the parameters to (void *).

msaxon
Active Participant

Re: memmove problem

> I'm afraid that you have misunderstood.  I want to move char* not char.

Whoops! Sorry!

--
Martin
Certified CVI Developer
Dave Byrne
Member

Re: memmove problem

Martin,

I hope that my original reply didn't seem brusque; it wasn't meant to be.  I'm sure to need your assistance in the future.

Dave

msaxon
Active Participant

Re: memmove problem

No, no - I've only been writing C for 30 years, I ought to be able to read it by now :-)
--
Martin
Certified CVI Developer
LuisG
NI Employee (retired)

Re: memmove problem

Hi Dave,

We've confirmed that this was a bug in the CVI user protection code that was causing the GPF. Your code should have run fine in debug mode also. Anyway, the bug was fixed, and it will be rolled into an upcoming maintenance release of 8.1.

Thanks for reporting this!

Luis