Struct compares/copies

[bb]

Q: I need to copy and compare C Structs.

Is this the safe and quick way to do it?:

void func(void)
{
typedef _MY_STRUCT
{
int a;
char b;
char c;
} my_struct

my_stuct new;
my_struct old;

if (memcmp(old,new,sizeof(new))
{
memcpy(old, new, sizeof(new));
}
}

 

[bb]

Q: I need to copy and compare C Structs.

Is this the safe and quick way to do it?:

void func(void)
{
typedef struct _MY_STRUCT
{
int a;
char b;
char c;
} my_struct;

my_stuct new;
my_struct old;

if (memcmp(old,new,sizeof(new))
{
memcpy(old, new, sizeof(new));
}
}

typos corrected!

 

[deepak]

Q: I need to copy and compare C Structs.

Is this the safe and quick way to do it?:

void func(void)
{
typedef _MY_STRUCT
{
int a;
char b;
char c;

} my_struct

my_stuct new;
my_struct old;

if (memcmp(old,new,sizeof(new))
{
memcpy(old, new, sizeof(new));
}



}- Hide quoted text -

- Show quoted text -

I think the use of memcmp in this code will be like,
if (!memcmp(old,new,sizeof(new))
{
memcpy(old, new, sizeof(new));
}

If the content is same why you need to copy it again?
Else for me code is ok.

 

[bb]

I think the use of memcmp in this code will be like,
if (!memcmp(old,new,sizeof(new))
{
memcpy(old, new, sizeof(new));
}

If the content is same why you need to copy it again?

Sorry, yes memcmp returns 0 if match. Typo (another one).

Else for me code is ok.

Sweet. Thank-you.

 

[Richard Heathfield]

(e-mail address removed) said:

Q: I need to copy and compare C Structs.

Is this the safe and quick way to do it?:

Copying is easy: new = old;

For safe and meaningful comparison, compare on a field-by-field basis,
comparing the most significant fields first. Typically one would write
a function to do this.

 

[Ben Bacarisse]

Sorry, yes memcmp returns 0 if match. Typo (another one).
Sweet. Thank-you.

It is not sweet -- the advice is wrong (except in the oddest of
situations). It is entirely possible for memcmp to return non-zero
when the two structures are equal in all important respects (i.e. have
identical values in all members).

 

[Clark Cox]

Q: I need to copy and compare C Structs.

Is this the safe and quick way to do it?:

[snip memcpy/memcmp-using code]


No. For copying, you can use the '=' operator in the obvious way:
old = new;

For comparing, you'll have to do that yourself, member-by-member. Using
memcmp isn't a good idea because it doesn't take into account any
padding that may be contained in the structure's layout (i.e. you could
actually be comparing bytes that don't contribute in any meaningful way
to the structure's value).

 

[bb]

Q: I need to copy and compare C Structs.

sniip


Copying is easy: new = old;

As the comapre (new == old) made the compiler unhappy I didn't want to
trust the assign (old = new).

For safe and meaningful comparison, compare on a field-by-field basis,
comparing the most significant fields first. Typically one would write
a function to do this.

Well once I've found a change I do have to go through each field to
and action the changes. However the changes are rare, so I wanted to
get the 'compare' over and done with asap, hence the 'old == new' as
there can be quite a few fields in the structure (20+ at the mo).

It is not sweet -- the advice is wrong (except in the oddest of
situations). It is entirely possible for memcmp to return non-zero
when the two structures are equal in all important respects (i.e. have
identical values in all members).

Well I have an odd situation because it has worked for me. Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

 

[Ben Bacarisse]

As the comapre (new == old) made the compiler unhappy I didn't want to
trust the assign (old = new).
Well once I've found a change I do have to go through each field to
and action the changes. However the changes are rare, so I wanted to
get the 'compare' over and done with asap, hence the 'old == new' as
there can be quite a few fields in the structure (20+ at the mo).

Well I have an odd situation because it has worked for me. Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

Yes, the problem is (mostly) structure padding. If you are certain
the there is none (on all the platforms you can foresee) or that you
have set to some known value in every case (because you have used
memset always) then you might me able to get away with it, but it
seems to me you would be making a fragile solution.

There is another sort of padding internal to some types that the
standard allows. Hence one can not assume that two values that
compare equal will be equal as far as memcmp is concerned.

Finally, some types have their own notion of equality that need not be
byte-for-byte equality. This is most obvious for floating point types
but it is also possible that two pointers might be == but have distinct
representations. Similarly, when a type permits trap representations,
the effect of == and memcmp may be different (but in this case the
memcmp will succeed in a possibly deceptive way).

BTW, it is probably not a good idea to join two answers together like
this. For one thing you can't easily keep the attribution lines (you
should have kept them, in my opinion).

 

[CBFalconer]

.... snip on comparing structs ...

It is not sweet -- the advice is wrong (except in the oddest of
situations). It is entirely possible for memcmp to return
non-zero when the two structures are equal in all important
respects (i.e. have identical values in all members).

The reason is that there can be padding bytes, which contain data
that has nothing to do with the value of the struct. You have to
compare field by field.

 

[Barry Schwarz]

As the comapre (new == old) made the compiler unhappy I didn't want to
trust the assign (old = new).

Trust has nothing to do with it. It is a question of what
capabilities the language provides. If you don't have a decent
reference manual, get one.

Well once I've found a change I do have to go through each field to
and action the changes. However the changes are rare, so I wanted to
get the 'compare' over and done with asap, hence the 'old == new' as
there can be quite a few fields in the structure (20+ at the mo).

Well I have an odd situation because it has worked for me. Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

Padding is one situation where equal structures can have mismatched
bits. Pointers are another - it is possible for two pointers to the
same address to have different bit representations. A system that
supports -0 is another. 0 and -0 must compare equal but will not have
the same bit representation. There probably are other situations
also.


Remove del for email

 

[Roland Pibinger]

Well once I've found a change I do have to go through each field to
and action the changes. However the changes are rare, so I wanted to
get the 'compare' over and done with asap, hence the 'old == new' as
there can be quite a few fields in the structure (20+ at the mo).

C++ gives you no automatic operator==() and Java no sematically
correct equals(). Why expect it from C?

Well I have an odd situation because it has worked for me.

You can get away with it if false negatives (false un-equals) are not
a problem. The code 'just' looks deficient.

Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

Look for 'structure padding' e.g. http://c-faq.com/struct/padding.html

 

[Army1987]

As the comapre (new == old) made the compiler unhappy I didn't want to
trust the assign (old = new).
Well once I've found a change I do have to go through each field to
and action the changes. However the changes are rare, so I wanted to
get the 'compare' over and done with asap, hence the 'old == new' as
there can be quite a few fields in the structure (20+ at the mo).

Well I have an odd situation because it has worked for me. Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

Even if there is no padding, the structures

struct words {
char word1[8] = { 'H', 'e', 'l', 'l', 'o', '\0', 42, 73 }
char word2[8] = { 'w', 'o', 'r', 'l,' 'd', '\0', 1, 95 }
} a;

and

struct words {
char word1[8] = { 'H', 'e', 'l', 'l', 'o', '\0', 12, 23 }
char word2[8] = { 'w', 'o', 'r', 'l,' 'd', '\0', 47, 79 }
} b;

don't memcmp equal, even if any reasonable person shouldn't
distinguish them in most cases.

 

[Ben Bacarisse]

Well I have an odd situation because it has worked for me. Can you (if
you have the time and inclination) tell me why memcmp would do this
(is it because of 'structure' padding/alignment and that two
'identical' structs not being identical)? I was concerned (hence the
question in the 1st place).

Even if there is no padding, the structures

struct words {
char word1[8] = { 'H', 'e', 'l', 'l', 'o', '\0', 42, 73 }
char word2[8] = { 'w', 'o', 'r', 'l,' 'd', '\0', 1, 95 }
} a;

and

struct words {
char word1[8] = { 'H', 'e', 'l', 'l', 'o', '\0', 12, 23 }
char word2[8] = { 'w', 'o', 'r', 'l,' 'd', '\0', 47, 79 }
} b;

don't memcmp equal, even if any reasonable person shouldn't
distinguish them in most cases.

A good example, although I feel it worth pointing out to budding
programmers that this problem is rather different in that it can be
avoided (at least in principle) by careful use of these fixed-length
arrays. The other problems cited can't be avoided by the programmer.