Why Does `%x` Format Differ for -1 in Go and C?

Conflicting Hexadecimal Formatting in Go and C: Understanding Signed vs. Unsigned Integers

In the world of programming, the formatting of integer values can sometimes lead to surprises. One such instance arises when printing 64-bit integers as hexadecimal deviates in Go and C.

The Issue

As the example demonstrates, using the %x format specifier on the integer value -1 in Go results in "-1," whereas in C, the expected output would be "ffffffffffffffff." This discrepancy stems from the fundamental difference in how Go and C handle signed and unsigned integers.

Go's Approach

Go strictly adheres to type safety. When formatting an integer value, it defaults to representing it as a signed integer, even if the input value is the negative representation of a large unsigned integer. The %x format specifier in Go formats the numerical value rather than its memory representation.

C's Approach

In contrast, C does not enforce strict type safety. The %x conversion in C typically formats the memory representation of the integer value, which in the case of a negative integer, is interpreted as a positive unsigned integer with equivalent bits.

The Solution in Go

To achieve the desired behavior in Go, it is necessary to explicitly convert the signed integer to an unsigned integer before applying the %x format specifier. This can be done using the uint type cast:

fmt.Printf("%d %x %d %x", -1, -1, uint(-1), uint(-1))

Output:

-1 -1 18446744073709551615 ffffffffffffffff

Rob Pike's Reasoning

The default behavior of representing negative numbers in their signed form in Go was a deliberate choice made by Rob Pike. His rationale was that it allows for shorter representations of negative numbers and ensures that all integer format specifiers (%b, %o, %d, %x) treat their arguments consistently.

The above is the detailed content of Why Does `%x` Format Differ for -1 in Go and C?. For more information, please follow other related articles on the PHP Chinese website!