Go Back   Rhinocerus > Newsgroup > Newsgroup comp.lang.c > Newsgroup comp.lang.c.moderated

Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old 12-10-2011, 09:04 AM
navy
Guest
 
Posts: n/a
Default copying structure members shifts by one byte when using memcpy()

Hi,

I am working in ubuntu linux 8.04 version and using gcc compiler for
compiling my application.
I am using a function as below

uint8 Message(uint8 u8SignalID, tstControlMessageData
*pstControlMessageData)
{
tstControlMessage stControlMessage;
uint8* char_ptr;
uint8 iCount;
char temp_buffer[100] = {0};


for (iCount = 0; iCount < sizeof(tstControlMessageData); iCount++)
{
sprintf (temp_buffer, "pstCMData->au8Data[%d] = %d\n", iCount,
pstControlMessageData->au8Data[iCount]);
puts(temp_buffer);
memset(temp_buffer, 0, 100);
}


memset(&stControlMessage, 0, sizeof(tstControlMessage));
stControlMessage.u8SignalID = u8SignalID;

memcpy(stControlMessage.stControlMessageData.au8Da ta,
pstControlMessageData->au8Data, sizeof(tstControlMessageData));

iCount = 0;
char_ptr = &(stControlMessage);
while ((char_ptr != NULL) && (iCount <
sizeof(tstControlMessage))){
sprintf(temp_buffer, "stCM[%d] = %d\n", iCount,
*char_ptr);
puts(temp_buffer);
char_ptr++;
iCount++;
}

return Cas_IPC_u8SendInternalMessage(&stControlMessage);
}


The problem i am facing is while copying structure data members using
memcpy gets copied in the destination location shifted by one byte.

I am posting teh log also for u to look into

source
pstControlMessageData->au8Data[0] = 1

pstControlMessageData->au8Data[1] = 6

pstControlMessageData->au8Data[2] = 255

pstControlMessageData->au8Data[3] = 255

pstControlMessageData->au8Data[4] = 255

pstControlMessageData->au8Data[5] = 255

pstControlMessageData->au8Data[6] = 255

pstControlMessageData->au8Data[7] = 255

pstControlMessageData->au8Data[8] = 18

pstControlMessageData->au8Data[9] = 15

pstControlMessageData->au8Data[10] = 23

pstControlMessageData->au8Data[11] = 22

destination
stControlMessage.stControlMessageData.au8Data[0] = 21

stControlMessage.stControlMessageData.au8Data[1] = 1

stControlMessage.stControlMessageData.au8Data[2] = 6

stControlMessage.stControlMessageData.au8Data[3] = 255

stControlMessage.stControlMessageData.au8Data[4] = 255

stControlMessage.stControlMessageData.au8Data[5] = 255

stControlMessage.stControlMessageData.au8Data[6] = 255

stControlMessage.stControlMessageData.au8Data[7] = 255

stControlMessage.stControlMessageData.au8Data[8] = 255

stControlMessage.stControlMessageData.au8Data[9] = 18

stControlMessage.stControlMessageData.au8Data[10] = 15

stControlMessage.stControlMessageData.au8Data[11] = 23


Here as u see, the first byte pstControlMessageData->au8Data[0] in the
source holds value 1. But the data copied in destination is
stControlMessage.stControlMessageData.au8Data[0] = 21

I suspect some background manipulation happening in memcpy.

I am using ubuntu linux 8.04 distribution and gcc compiler
The application runs on 32 bit Fujitsu JADE processor

Can anybody throw light on this problem



- Navy
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
Alt Today
Advertising
 
and become member of Rhinocerus
Standard Sponsored Links

  #2 (permalink)  
Old 12-11-2011, 04:58 AM
Hans-Bernhard Bröker
Guest
 
Posts: n/a
Default Re: copying structure members shifts by one byte when using memcpy()

On 10.12.2011 11:04, navy wrote:
> sprintf (temp_buffer, "pstCMData->au8Data[%d] = %d\n", iCount,
> pstControlMessageData->au8Data[iCount]);
> puts(temp_buffer);


Why bother with temp_buffer? A plain and simple printf() would have
done the job more cleanly.

> memcpy(stControlMessage.stControlMessageData.au8Da ta,
> pstControlMessageData->au8Data, sizeof(tstControlMessageData));


This looks dubious. You're copying one element of the source structure,
but you specify the size of the /entire/ structure. That's basically a
buffer overflow waiting to happen.

> iCount = 0;
> char_ptr =&(stControlMessage);
> while ((char_ptr != NULL)&& (iCount< sizeof(tstControlMessage))){
> sprintf(temp_buffer, "stCM[%d] = %d\n", iCount, *char_ptr);


Note that this prints the /entire/ struct, not just the au8Data part you
copied via memcpy() before. That's basically the same problem as the
memcpy size above.

> The problem i am facing is while copying structure data members using
> memcpy gets copied in the destination location shifted by one byte.


You haven't actually demonstrated that. For all you've showed, that
additional byte is just the 'u8SignalID' member.

The code you showed also doesn't actually produce the output you showed.

> I suspect some background manipulation happening in memcpy.


Your suspicion is based on lack of understanding.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
  #3 (permalink)  
Old 12-11-2011, 04:58 AM
James Lothian
Guest
 
Posts: n/a
Default Re: copying structure members shifts by one byte when using memcpy()

navy wrote:
> Hi,
>
> I am working in ubuntu linux 8.04 version and using gcc compiler for
> compiling my application.
> I am using a function as below


Difficult to tell what's going on without the declarations of the
structs, but anyway...
>
> uint8 Message(uint8 u8SignalID, tstControlMessageData
> *pstControlMessageData)
> {
> tstControlMessage stControlMessage;
> uint8* char_ptr;
> uint8 iCount;
> char temp_buffer[100] = {0};
>
>
> for (iCount = 0; iCount< sizeof(tstControlMessageData); iCount++)
> {
> sprintf (temp_buffer, "pstCMData->au8Data[%d] = %d\n", iCount,
> pstControlMessageData->au8Data[iCount]);
> puts(temp_buffer);
> memset(temp_buffer, 0, 100);
> }
>
>
> memset(&stControlMessage, 0, sizeof(tstControlMessage));
> stControlMessage.u8SignalID = u8SignalID;
>
> memcpy(stControlMessage.stControlMessageData.au8Da ta,
> pstControlMessageData->au8Data, sizeof(tstControlMessageData));


So here you copy some data into stControlMessage.stControlMessageData.au8Data...
>
> iCount = 0;
> char_ptr =&(stControlMessage);
> while ((char_ptr != NULL)&& (iCount<
> sizeof(tstControlMessage))){
> sprintf(temp_buffer, "stCM[%d] = %d\n", iCount,
> *char_ptr);
> puts(temp_buffer);
> char_ptr++;
> iCount++;
> }

.... and here you try to get the data back out of stControlMessage itself, rather
than stControlMessage.stControlMessageData.au8Data. And additionally, the test
char_ptr != NULL looks very bogus. Shouldn't that
be dereferencing the pointer?

James


--
---------------------------------------------
demangle my email address in the obvious way.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
  #4 (permalink)  
Old 12-11-2011, 04:59 AM
Jasen Betts
Guest
 
Posts: n/a
Default Re: copying structure members shifts by one byte when using memcpy()

On 2011-12-10, navy <navin86ls@gmail.com> wrote:

> memcpy(stControlMessage.stControlMessageData.au8Da ta,
> pstControlMessageData->au8Data, sizeof(tstControlMessageData));


it's generally good idea to keep identifiers to 8 chaacters or shorter.
AFIAK this GCC can handle identifiers or much larger, but not all
compilers can.

you don't show the initialisation of
stControlMessage.stControlMessageData.au8Data
or pstControlMessageData->au8Data

is it possible the the source and destnation ranges given to memcpy
overlap?


--
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
  #5 (permalink)  
Old 12-14-2011, 05:37 PM
Francis Glassborow
Guest
 
Posts: n/a
Default Re: copying structure members shifts by one byte when using memcpy()

On 11/12/2011 05:59, Jasen Betts wrote:
> On 2011-12-10, navy<navin86ls@gmail.com> wrote:
>
>> memcpy(stControlMessage.stControlMessageData.au8Da ta,
>> pstControlMessageData->au8Data, sizeof(tstControlMessageData));

>
> it's generally good idea to keep identifiers to 8 chaacters or shorter.
> AFIAK this GCC can handle identifiers or much larger, but not all
> compilers can.


Well if they cannot handle at least 31 characters in an external
identifier they do not conform to the requirements of 5.2.4.1 of the
1999 C Standard.

It is usually a good idea to ensure that ids with external linkage are
reasonably meaningful and unlikely to collide with a similar name in
third party code. (possible a much better use of leading characters than
using (the atrocious) hungarian notation.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
  #6 (permalink)  
Old 12-14-2011, 05:38 PM
James Kuyper
Guest
 
Posts: n/a
Default Re: copying structure members shifts by one byte when using memcpy()

On 12/10/2011 05:04 AM, navy wrote:
> Hi,
>
> I am working in ubuntu linux 8.04 version and using gcc compiler for
> compiling my application.
> I am using a function as below
>
> uint8 Message(uint8 u8SignalID, tstControlMessageData
> *pstControlMessageData)
> {
> tstControlMessage stControlMessage;
> uint8* char_ptr;
> uint8 iCount;
> char temp_buffer[100] = {0};
>
>
> for (iCount = 0; iCount < sizeof(tstControlMessageData); iCount++)
> {
> sprintf (temp_buffer, "pstCMData->au8Data[%d] = %d\n", iCount,
> pstControlMessageData->au8Data[iCount]);


Here, you're printing out the elements of pstControlMessageData->au8Data.

It's name suggests that au8Data may be an array of some 8-bit type; the
same is implied by the name uint8. That would justify your comparison of
the two outputs. However, it would have been better to give us a
declaration for all non-standard types used in your program, including
both uint8 and tstControlMessageData.

> puts(temp_buffer);
> memset(temp_buffer, 0, 100);
> }
>
>
> memset(&stControlMessage, 0, sizeof(tstControlMessage));
> stControlMessage.u8SignalID = u8SignalID;
>
> memcpy(stControlMessage.stControlMessageData.au8Da ta,
> pstControlMessageData->au8Data, sizeof(tstControlMessageData));


Here, you've only copied over the
>
> iCount = 0;
> char_ptr = &(stControlMessage);


Here, you're printing out the bytes of stControlMessage.

Do you have any reason to believe that those bytes start at the same
location as the bytes that make up stControlMessage.au8Data? You've
given us no justification for assuming that this is the case. If
u8SignalId were a member of type uint8 that immediately preceded the
au8Data member, and if u8SignalId had a value of 22, that would explain
your discrepancy perfectly.


> while ((char_ptr != NULL) && (iCount <
> sizeof(tstControlMessage))){
> sprintf(temp_buffer, "stCM[%d] = %d\n", iCount,
> *char_ptr);
> puts(temp_buffer);
> char_ptr++;
> iCount++;
> }
>
> return Cas_IPC_u8SendInternalMessage(&stControlMessage);
> }
>
>
> The problem i am facing is while copying structure data members using
> memcpy gets copied in the destination location shifted by one byte.



--
James Kuyper
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Reply With Quote
 
Reply

Thread Tools
Display Modes

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 Off
Pingbacks are Off
Refbacks are Off




All times are GMT. The time now is 06:23 PM.


Copyright ©2009

LinkBacks Enabled by vBSEO 3.3.0 RC2 © 2009, Crawlability, Inc.