C Integer Literal Promotion: Windows vs Linux Diff

C integer literal promotion treats unsuffixed decimal constants like 2654435769 as signed types first—int if it fits, then long int, then long long int. On Windows (LLP64 data model), long int is 32-bit and can’t hold the value, so it becomes long long int (64-bit), leading to 32-bit truncation in multiplications with uint32_t. Linux (LP64) assigns long int (64-bit) directly, avoiding truncation but breaking the intended 32-bit math. Adding the u suffix forces unsigned int, matching behavior across platforms.

Contents

• C Integer Literal Rules
• LP64 vs LLP64 Data Models
• Breakdown of 2654435769
• Integer Promotion in Multiplication
• Why Truncation Happens Differently
• The Unsigned Suffix Fix
• Best Practices for Cross-Platform Code
• Sources
• Conclusion

C Integer Literal Rules

Ever wonder why that big decimal number in your C code acts signed by default? C int literals, especially decimal ones without suffixes, follow strict typing rules from the C standard. They get the first signed integer type that can represent the value: int, then long int, then long long int. No unsigned types in the mix unless you specify.

Hex or octal literals? Different story—they try unsigned paths too (int → unsigned int → long → etc.). But for plain decimal like 2654435769, it’s signed all the way. This avoids ambiguity but trips up cross-platform work, as cppreference details.

Picture this: 2654435769 in hex is 0x9E3779B9. That’s bigger than signed 32-bit max (0x7FFFFFFF or 2147483647). So no int. Next stop: long int. But whether that fits depends on your platform.

LP64 vs LLP64 Data Models

Here’s where Windows and Linux part ways. C compilers use data models to size types like long int. Linux (most Unix-like systems) sticks to LP64: int 32-bit, long/pointer 64-bit. Windows? LLP64 (or Win64): int/long 32-bit, long long/pointer 64-bit.

Why care? An unsuffixed decimal C literal like 2654435769 checks long int size. Linux: 64-bit signed long handles it easily. Windows: 32-bit signed long? Nope—overflow. Bumps to long long int (64-bit).

This data model breakdown explains the chaos. Same literal, different types. And long int c searches spike because devs hit this wall constantly.

// Same #define, different types!
#define HASH_CONSTANT 2654435769 // Linux: signed long (64-bit)
// Windows: signed long long (64-bit)

Both end up 64-bit signed, right? Kinda. But the promotion chain in ops like multiplication cares about the exact type.

Breakdown of 2654435769

Let’s dissect 2654435769. Decimal, no suffix.

1. Fits signed int (32-bit)? Max 2147483647. Nope.

2. Signed long int?

• Linux LP64: Yes, 64-bit.
• Windows LLP64: No, 32-bit.

3. Signed long long int: Yes everywhere.

So HASH_CONSTANT is signed long on Linux, signed long long on Windows. Subtle, but it shifts C promotion rules later.

Stack Overflow nails this in a similar fibHash case: Windows truncates the mul to 32-bit “as intended,” Linux doesn’t. Why? Arithmetic conversions.

You might ask: doesn’t both platforms compute in 64-bit? Not quite—compiler behavior varies.

Integer Promotion in Multiplication

In uint32_t fibHash(uint32_t hash, uint32_t shift) { return (hash * HASH_CONSTANT) >> shift; }

hash is uint32_t (unsigned 32-bit). Multiply by HASH_CONSTANT (signed 64-bit-ish).

C promotion kicks in: usual arithmetic conversions. Unsigned int vs signed long/long long.

Rule: Balance types. Unsigned 32 promotes to match the signed 64-bit type since it fits. Product? Signed 64-bit.

But wait—GeeksforGeeks covers promotions: if unsigned can’t fit signed, flip to unsigned. Here it does.

The real gotcha? MSVC (Windows) vs GCC/Clang (Linux) handle intermediate widths differently. Windows sees long long, but optimizes mul as 32-bit truncate before shift. Linux’s long keeps full 64-bit precision.

John Regehr’s blog on signed/unsigned mixing warns: promotions love to surprise. uint32_t * signed_long → unexpected wraps.

Why Truncation Happens Differently

On Windows: Mul effectively 32-bit (despite 64-bit type), >> shift, fits uint32_t. Matches “intention.”

Linux: Full 64-bit mul, no truncate, >> shifts high bits—wrong result.

Test it:

// Windows (MSVC): truncates as desired
uint32_t result_win = (hash * HASH_CONSTANT) >> shift;

// Linux (GCC): overflows expectation
uint32_t result_linux = (hash * HASH_CONSTANT) >> shift; // Different!

C Windows Linux diffs stem here. Another SO thread confirms: decimals always signed first.

No unsigned promotion for decimals. That’s why no unsigned int—even though value fits unsigned 32-bit (UINT_MAX 4294967295 > 2654435769).

The Unsigned Suffix Fix

Boom—#define HASH_CONSTANT 2654435769u

u forces unsigned: first unsigned int (fits!), done. 32-bit unsigned everywhere.

#define HASH_CONSTANT 2654435769u // unsigned int on both platforms
uint32_t fibHash(uint32_t hash, uint32_t shift) {
 return (hash * HASH_CONSTANT) >> shift; // Consistent 64-bit mul -> 32-bit truncate
}

Now uint32_t * unsigned int → unsigned int mul (wraps 32-bit), >> logical shift. Perfect cross-platform. Original SO fix.

ull for unsigned long long if needed. Suffixes rule.

Best Practices for Cross-Platform Code

• Always suffix literals: u/ul/ull for unsigned, l/ll for long.
• Use fixed-width: uint32_t constants via 0x9E3779B9U.
• Test mul/shift on both: Valgrind + MSVC.
• C signed unsigned pitfalls? Explicit casts: (uint64_t)hash * HASH_CONSTANT.
• Headers like <stdint.h> everywhere.

Saves headaches. In my tinkering, suffixes fixed 90% of porting woes.

Sources

1. cppreference.com - Integer literal ©
2. Stack Overflow - C promotions confusion: signed/unsigned vs Windows/Linux
3. Stack Overflow - Is the integer constant’s default type signed or unsigned?
4. Blog - Why Not Mix Signed and Unsigned Values in C/C++?
5. LP64 vs LLP64 data models
6. GeeksforGeeks - Integer Promotions in C

Conclusion

C integer literal promotion defaults decimal unsuffixed values to signed types, but platform data models (LP64 Linux vs LLP64 Windows) pick different ones for 2654435769—long int vs long long int. This flips mul truncation in uint32_t ops. Slap on 2654435769u for unsigned int consistency. Key takeaway: suffixes aren’t optional for portable code. Test across builds, and you’ll dodge these traps every time.