Member Avatar for Learningvinit

Hi All,

While running a piece of code on Linux and HP i found the differenc in the result.
Can Anyone Explain Why it is giving different results?

#include <stdio.h>

int main()
{
    int a = 0;
    int b = 30030;
    int c = 34094;
    int d = 0 ;
    d = memcmp(&b,&c,sizeof(int));
    printf ("Comparison between b and c : %d",d);
    return 0;
}

On HP : This returns : “Comparison between b and c : -16”
On Linux This returns : “Comparison between b and c : 1”

  • 4 Contributors
  • 5 Replies
  • 624 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by Learningvinit

Dani AI

Generated

Short version: memcmp looks at raw bytes, not numeric value. That makes its ordering depend on the machine's byte order (endianness) and on how bytes are interpreted; different architectures can therefore give opposite signs even though both results are “correct.” This is why saw different outputs, and why and pointed to endianness while noted the return-value convention.

Practical guidance you can apply immediately:

  • For numeric comparisons, compare integers as integers. That is portable and unambiguous:
if (b < c)   /* b less than c */
else if (b > c) /* b greater than c */
else /* equal */
  • If you must compare the in-memory byte sequences across machines (for example to detect identical serialized representations), normalize to a known byte order first. Use fixed-width types and convert to network order before memcmp:
#include <stdint.h>
#include <arpa/inet.h>   /* htonl/ntohl on POSIX */

uint32_t xb = htonl((uint32_t)b);
uint32_t xc = htonl((uint32_t)c);
int r = memcmp(&xb, &xc, sizeof xb); /* now endian-independent */
  • Quick checks and cautions:
    • memcmp should only be used for byte-wise comparisons (e.g., buffers). For numeric equality/ordering, use relational operators.
    • Only the sign (<0, =0, >0) of memcmp is portable; do not rely on the magnitude of a nonzero return.
    • If you need to detect endianness at runtime, test a multi-byte value’s lowest-address byte (e.g., check whether (uint8_t)&(uint16_t){1} == 1).

This expands on the thread answers: use relational ops for values, or serialize/canonicalize (htonl/defined byte-swap) before memcmp when you really need consistent byte-level comparison across platforms.

Recommended Answers

All 5 Replies

Member Avatar for Adak

The more common convention would be 1, 0, or -1. The standard may allow any value > 0 < 0 or 0 (as is seen with strcmp(), a very similar function).

The negative value in one, and the positive value in the other, is a problem however. Could it be that the sizeof(int) is different on these systems, when you print it out?

Edited by Adak
Member Avatar for Learningvinit

Size of int is 4 on both system.

Member Avatar for deceptikon

Could you be more specific about the OSes in question? I suspect that it's an endianness issue. I'm not aware of HP-UX support on little endian architectures, but Linux supports both big and little endian depending on the hardware. If you're running Linux on something like an x86 then I'm not surprised you're getting reversed results from the two platforms.

Member Avatar for Banfa

I imagine this is an endian issue. When storing an integer in memory little endian processors store least significant byte first, big endian processors store most significant byte first.

So the numbers are stored in memory as follows

30030 
little endian machine: 4E 75 00 00
big endian machine:    00 00 75 4E

34094
little endian machine: 2E 85 00 00
big endian machine:    00 00 85 2E

Taking -16 to mean second one bigger and 1 to mean first one bigger and remembering that memcmp compares a byte at a time then.

On a little endian, Linux, it compares
1st Byte: 4E with 2E; they are different, 4E is bigger so the first parameter is bigger so it returns 1 and stops.

On big endian, HP, it compares:
1st Byte: 00 with 00, the same continue to 2nd byte
2nd Byte: 00 with 00, the same continue to 3rd byte
3rd Byte: 75 with 85; they are different, 75 is smaller so return negative. It is doing the comparison by subtraction and returning the result if it is not 0, 0x75 - 0x85 = -16

That is how you get different results on different machines with them both being correct.

Edited by Banfa
Member Avatar for Learningvinit

I got it it's an endian issue....

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.