Negative numbers not represented by in-memory two's complement binary value when formatted with {b}

[ZeikJT]

Zig Version

0.14.0-dev.3217+5b9b5e45c

Steps to Reproduce and Observed Behavior

Simply try and print a negative number with {b}

const num1: i16 = 210;
const num2: i16 = -210;
std.debug.print("{b}\n", .{ num1 }); // 11010010
std.debug.print("{b}\n", .{ num2 }); // -11010010

As you can see, the negative number is printing the positive bit pattern with a - prefix. This is not how the number is actually being represented in memory.

Check out how confusing this is:

std.debug.print("{b}\n", .{-210}); // -11010010
std.debug.print("{b}\n", .{0b1000000000000000 & -210}); // 1000000000000000

Expected Behavior

I would expect the number to be printed as it is in memory, with the two's complement bit pattern. The docs state that Zig uses two's complement and we can verify this in code by forcing the literal bits into an unsigned int before printing:

const num: i16 = -210;
const numU: u16 = @bitCast(num);
std.debug.print("{b}\n", .{ numU }); // 1111111100101110

The above is how I'd expect it to print -210 with {b} by default, without having to forcibly bitCast it to an unsigned.

[robbielyman]

for what it’s worth, this could be interpreted as “working as expected”: binary as a system for representing numbers has no understanding of two’s complement, but it does have negative and positive numbers. likewise with hex, which is similarly used in some cases as a compact representation of what is happening in memory. if you want to see the bits, it might be clearer to @bitCast to an unsigned type and print that with {b}. preserving the more obviously “mathematically correct” operation (i.e. ignore two’s complement) for signed integers seems desirable to me.

[mrjbq7]

I like the current behavior...

[ZeikJT]

If you're going to be working with binary operations and visualizing the binary itself, via shifting and masking and such, it just feels like it makes sense to have it print the actual bit pattern, otherwise you're working more or less in the dark. Seems like other people are using the representation for something else where it makes sense to not see the actual in-memory representation?

[190n]

Seems like other people are using the representation for something else where it makes sense to not see the actual in-memory representation?

I haven't used {b} very much myself, but I would expect the current behavior for negative numbers and I would not expect the behavior you're proposing. I expect number formatting functions to print the mathematical value of a number expressed in a given base, which may not be the same thing as its in-memory representation (even when the chosen base is 2). If I wanted to see the in-memory representation I would @bitCast to an unsigned integer or a byte array.

[rootbeer]

I'm surprised by the current behavior too. But it seems this (logical negative) is how Python formatters, at least, work, while the alternative (raw bit pattern) is how C/C++ printf works. So my bias is probably coming from C's printf behavior. See https://stackoverflow.com/questions/3831833/printing-negative-values-as-hex-in-python for a head-to-head comparison.

The thumbs up/down votes on this post are definitely in favor of the status quo at the moment...

[chung-leong]

I'm in favor of new specifiers explicitly designed for debugging purpose that work for all types:

std.debug.print("{bits}\n", .{num1});

00001111 00101011

std.debug.print("{bytes}\n", .{num1});

0F 2B