Re: question about memcpy()
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Mon, 01 May 2006 21:19:22 -0400
Besides the #pragma pack(push,1) issue I have already addressed, this code is so
screamingly suspect that I'm amazed it could have ever been assumed to have worked.
For example, it assumes that an exact bit image of a MAC_ADDR structure is laying in
buff[1..sizeof(MAX_ADDR)], which could only have happened if there was already a copy of
those bits from a MAC_ADDR structure. There is no way to tell how the packing went, and
there is no indication of why there is the slightest reason to believe that this buffer
actually exists. It is also worth noting that 100 is a completely magic number, because
as far as I can tell, sizeof(MAX_ADDR) will be AT LEAST 6+1+4+4+4+80+80, or 181, so how a
181-byte structure can be packed into a 100 byte buffer (actually, only 99 bytes are used,
because it is from &buff[1], which is clumsily expressed as buff+1 (and PLEASE learn to
put spaces after commas to make the code readable!) so the memcpy itself is at best
complete nonsense and at worst could cause access faults or other pathologies. When the
effects of padding are considered, the problem becomes worse.
At the very least, the size of the buff should be a whole lot larger than it is, and it
should be given as sizeof(MAC_ADDR)+1 (to allow for that [1] offset), rather than a random
(and erroneous) value like 100.
The fact that it doesn't work across compilers is almost certainly due to packing issues,
but a better solution, instead of memcpy, would have been
resp = *(MAC_ADDR *)&buff[1];
but it is essential that the data have been stored by doing
*(MAC_ADDR *)&buff[1] = *p; // MAC_ADDR * p;
any attempt to play with bits as shown here is considered "non-portable" by the ISO/ANSI
standard and in fact is NOT guaranteed to work (explicitly, by the definition of the
standard). And guess what? It wasn't portable! (Code like this should never have been
written in the first place, so the fact that it doesn't work should come as no surprise at
all).
joe
On 25 Apr 2006 15:23:50 -0700, "kathy" <yqin_99@xxxxxxxxx> wrote:
I have a class which is called in both my Studio 6 project andJoseph M. Newcomer [MVP]
Studio.NET 2003 project.
In Studio 6 project, it works fine. But in Studio.NET 2003 project, it
failed.
The piece of code in the class:
-------------------------------------------
typedef struct _new_params
{
char newf;
unsigned long ip_address;
unsigned long netmask;
unsigned long gateway;
} NEW_PARAMS;
typedef struct
{
unsigned char addr[6];
NEW_PARAMS params;
char ID_String[80];
char Address[80];
} MAC_ADDR;
char buff[100];
MAC_ADDR resp;
...
memcpy(&resp,buff+1,sizeof(MAC_ADDR)); //set break point here
...
The buff data is SAME in both projects. But after the memcpy(...), the
resp contents are different !!! The studio 6 is correct and the
Studio.NET2003 is wrong. Why?
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
.
- Prev by Date: Re: question about memcpy()
- Next by Date: Re: question about memcpy()
- Previous by thread: Re: question about memcpy()
- Next by thread: Re: question about memcpy()
- Index(es):
Relevant Pages
|
