Rationale for struct assignment and no struct comparison

[Michael Foukarakis]

 And I don't remember ever actually *needing*
to compare two records/structs for equality.  Logical equivalence
is very often more complicated than member-by-member equality.

You mean you've never worked with the dreaded struct timeval, or are
you still referring to that Ada project (because I can easily see that
happening)?

 

[Michael Foukarakis]

Additional question:
After an assignment s2=s1;
is s2 bit-for-bit identical to s1
or does the padding have unspecified values?

Regards.

According to the standard (C99 here):

* When a value is stored in an object of structure or union type,
including in a member
* object, the bytes of the object representation that correspond to
any padding bytes take
* unspecified values.

So yeah, a bit-for-bit comparison is out of the question.

 

[Phil Carmody]

Interesting. I developed a pretty much parallel language to C in the
1980's.

That /did/ have struct compares, and it seemed work!

However, my structs didn't have 'holes', as I knew nothing about C's method
of automatic padding (I did this manually as needed.)

Even with holes, I can imagine various schemes to compare two structs that
would not require an arbitrarily large amount of code (such as looping
through a bitmap showing the bytes that need to match, or finding out
exactly what the difficulty is in making sure padding bytes are zero) .

Padding bytes (and padding bits, for bit-fields) mightn't
be the only problem. For example:

struct { char c[100]; }
x = { "Hello" }, y = { "Hello" };
x.c[99] = 'x';
y.c[99] = 'y';
assert (strcmp(x.c, y.c) == 0);
assert (x == y); /* ??? */

The structs x,y are "equal" if their c arrays are thought of
as containing strings, "unequal" if they're thought of as
holding a hundred characters each.

Good! A point of view supported by all sane programmers, and also by
the introduction of == on structs.

Somehow I think you weren't trying to present an argument *for* =='s
introduction though; hmmm...

Phil

 

[Keith Thompson]

You mean you've never worked with the dreaded struct timeval, or are
you still referring to that Ada project (because I can easily see that
happening)?

I've worked with struct timeval, but I've never felt the need to
compare two struct timeval values for equality.

 

[Nick Keighley]

bartc wrote:

) It happens from time to time. In recent code I have a 4-byte composite value
) (an array, but it could have been a struct) which I have to compare with
) another.
)
) It not's a big deal in C to interpret each composite as an integer, but it
) would have been neater to have allowed == directly.

It's even simpler to just use memcpy().

ITYM memcmp()?

 

[Nick Keighley]

The *definition* of the two operations are not even of similar
complexity.

If you try to use structure comparison, you will constantly be
running into problems:

- You can't count on the padding bits.
- The contents of character arrays after the terminating \0 are
  still part of the array and will be compared, but you may not
  want them to be.
- Floating-point fields don't necessarily have to be bit-for-bit
  identical to be equal (IEEE floating point mandates two values
  for zero).
- The fields are rarely in the right order for a > or < comparison.
- Structure assignment can use memcpy().  For a > or < comparison,
  you need to know the types involved, as signedness and endianness
  messes up comparing ints (or worse, doubles) by looking at the
  representation as unsigned char.  Little-endian multi-byte integers
  will be a problem here.
- You will sometimes want pointer comparisons to compare what the
  pointer points *AT*, not the value of the pointer itself.  Other
  times you won't.

interesting