In the interactive mode or command-line mode ?
I don't see where I can fit it in the interactive mode.
Adding support for this in command line is pretty straight forward.

Both. You only need one column for a sign in interactive mode, no?

Maybe you could have two boxes for decimal/octal/hex where one is unsigned and the other signed. You don't need an extra box for base-2 representation, naturally.

It's very uncommon to represent signed value in octal / hex / binary.
I do think that there's value in printing it in command line mode. I will add this to the tasks list.

Thanks!

Hello :-)
if this feature request is closed, does it mean it is implemented?
Thanks
--marco

edit: cause I don't know how to "activate/use" it (in case it is already implemented) couldn't find a hint in the ReadMe

It's implemented in command line mode. example:

bitwise 0x1520
*Unsigned decimal: 5408*
Signed decimal: 5408
Hexdecimal: 0x1520
Octal: 012440
Human: 5.28 KiB
ASCII: ........
Binary:
0 0 0 1 0 1 0 1 | 0 0 1 0 0 0 0 0
    15 -  8            7 -  0

and how can I pass a negative number?

bitwise -4

doesn't work of course, as it thinks it's a parameter.

and interactive mode?

it makes little sense to add it in interactive mode as it can't be represented in hex/octal.
I added the conversion only because it can assist when reverse engineering to see if a memory value is a signed value.

Maybe I don't fully get what you mean, but in (my/the) embedded systems world the hex (and octal) values are just used as a different representation of the binary form.
0xFF and 0b11111111 are simply the same for signed and unsigned. Only the decimal value changes depending on signed or unsigned interpretation. That's at least how we handle it at work. Don't know how others do it, but that's what I'm used to in the automotive industry.
I find that pretty useful when working with micro controllers etc. and I don't think hex (and octal) need to be represented differently for negative numbers.

don't get me wrong. I love this tool, and it's already pretty useful.

But don't you think that signed and even float should be interpreted too, while Hex Octal Binary representation stays the same?

No when I rethink it it makes sense. I'll try to see where can I fit it in.

You/we can do small steps.
On the top left bitwise shows the decimal value. What if the users could change for that decimal value the interpretation of the binary value with some keys. The hex and octal values on the mid and right top would be unaffected.

s to switch to signed interpretation
u to switch to unsigned interpretation (default as today)
f to switch to float interpretation
... of the binary which is shown below.

The interactive calculator at the bottom you don't have to change for that.

For float and signed some bits could be shown in a different color to highlight ...
in case of 'signed' interpretation -> the most left bit which stands for /-
in case of 'float' interpretation -> significand, mantissa, base, exponent or what they are called

Is this too much already? Maybe I got carried away :D

Anyways, awesome tool, even without changing anything. good job.

I won't bother you any longer. I already talked too much.
If you need further input just let me know.

I hope I can make it work on Cygwin then I can show it my colleagues. yeah

Thank you ;-)

--marco

and how can I pass a negative number?

bitwise -4

doesn't work of course, as it thinks it's a parameter.

In case it helps anyone else, there's an easy workaround for this limitation. Just formulate the number as an expression by subtracting the value from zero:

$ bitwise -w b '0 - 4'
Unsigned decimal: 252
Signed decimal: -4
Hexadecimal: 0xfc
Octal: 0374
Human: 252
Radix64: w1
ASCII: ........
Binary:
1 1 1 1 1 1 0 0
     7 -  0

I've missed the earlier comment about this this is a bug.
Actually, this is a common unix thing that when passing a parameter that starts with '-' you should separate the options by adding '--' before the expression:
bitwise -- -4

This should no pass the '-4' to the parser, but it appears that there's a bug there. I'll need to look in to it. meanwhile, I'll open a bug for it.

@rbarnard @marcotrosi
#42