I would agree on this for some cases (and I suspect more so for != NULL than != 0), but memcmp() != 0 isn't one of them. There are multiple reasons why, some more generic than others, but two of them are very specific to memcmp():

1. There are similar functions (like std::lexicographical_compare() in C++) returning bool instead an int.

2. It's not crazy to read memcmp() as comparing for equality rather than ordering. i.e. I think when you see 'if (memcmp(a, b, n))', it's quite natural for one's brain to read it as "if a and b are equal..."

For someone who uses memcmp() on a daily basis, you probably don't encounter these misconceptions. But as someone who writes C++ and merely deals with C once in a while in the process, both of these possibilities have tripped me up multiple times when seeing if (memcmp(...)). Writing != 0 has always cleared that confusion for me, since it immediately signals the result (a) isn't meant to be read as a Boolean, and (b) might be negative, thus putting my brain on alert.

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, 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!

Reading 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

I disagree. I avoid implicit casting, including truthiness. "== true" is indeed suspicious because you aren't avoiding anything, but to me "!= 0" or "!= nullptr" are crisper.

I don't know what you mean by "crisper", but in general I've noticed that extraneous code only increases the chance of bugs (and this is a good example of that.) if(foo) and if(!foo) are very common idioms and should be committed to the subconscious memory.

!= 0 should only be used for ints / floats / 'numbers'.

Comparing it to false requires me to know that false is 0. Comparing it to a ptr requires me to know that 0 represents a pointer pointing to nothing.

0 is the false value in C, no implicit casting or "truthiness" involved. The C standard explicitly defines if statements in terms of zero: "the first substatement is executed if the expression compares unequal to 0... [else] is executed if the expression compares equal to 0".

C does not have a boolean type. (The `true` and `false` defined in stdbool.h are macros expanding to the integer literals 1 and 0, respectively.)

C has a boolean type, it just doesn't have true and false constants in that type.

C23 replaces them with proper keywords.

Yes, although they still evaluate to 0 and 1 and conditional logic is still defined in terms of 0 and 1. Maybe that will change at some point in the future as well!

They aren’t testing for ‘false’ in this case but for success.

Functions which return 0 on success I always compare with 0 as “if (foo()) error();” easily gets confusing. If I see “if (foo() != 0) error();” then I can easily tell what’s going on because C is funny like that.

Conversely, if I’m testing for truthfulness or NULL I’ll use the boolean operators.

I write comparisons against 0 or false/true sometimes. There are places where it improves code clarity IMO.

It's not suspicious.

Also, put the constant value (0 or true or null) on the left side.

The Yoda conditional.

Former variable assignment conditional (FVAC), which is inferior to latter variable assignment (0=i) & conditional (i=0), but necessitated by the declaration syntax.

TIL. Loved it!

There are coding standards that don't allow implicit truthiness testing. They're misguided but they exist.

In C? C doesn't have a concept of truthiness, just zero and nonzero.

This is a stylistic choice. In my personal opinion, I agree with you. But I've seen styles that swear by the other way that you and I don't like. And I respect those who hold those opinions in good faith. I think someone once told me misra-c requires != 0.

So you would dislike seeing code like, say...

  if (!((my_ptr = malloc (sizeof (struct my_struct))) != NULL))
    exit (1);