3 ms·
When I used to write a lot of C code, my solution for this was to avoid calling memcmp() directly at all when I only cared about a yes/no on the match. Instead
by Stratoscope 4y ago
When I used to write a lot of C code, my solution for this was to avoid calling memcmp() directly at all when I only cared about a yes/no on the match. Instead I used a wrapper I called memeq():
int memeq( const void* lhs, const void* rhs, size_t count ) {
return memcmp( lhs, rhs, count ) == 0;
}
One could have an analogous memneq() with != 0, but I preferred to just use the ! operator on the memeq() result.
I would also use a typedef for the struct, so you don't have to keep writing "struct" everywhere:
typedef struct {
int x, y, z;
} tmp;
With those two tricks and more generous whitespace for clarity, the erroneous memcmp() call becomes:
if( ! memeq( m_result_original, m_result_my_version, sizeof(tmp) ) )
You're a lot less likely to get that wrong.
That said, this code, even with my updates, was wrong all along. Using memcmp() on two structs, even with a wrapper, is a bad idea. What if there is padding?!
This particular struct will not have padding, but in the more general case you shouldn't count on that.
What you really need to do is have a function that explicitly compares the x, y, and z fields of these two structs.
Then you won't have to worry about uninitialized padding, you will never get the length wrong, and everything will always just work.
- jcelerier 4y agoReading this makes me appreciate how nice it is in c++ to just be able to do operator==() = default; to let the compiler generate the appropriate comparator automatically