Add unique coloring for immediate values #19003

[vicky-dx]

Description

Implements unique color assignment for immediate values in disassembly output, making it easier to distinguish similar hex values like 0x1234567890abcdef vs 0x1234567890abcdee.

Changes

• Added config option scr.color.ops.unique (default: false)
• Added unique_colors boolean field to RPrint structure
• Implemented hash-based deterministic color palette with 10 distinct colors
• Identical immediate values consistently receive the same color
• Different values receive different colors (with acceptable ~10% collision rate)

Usage

e scr.color.ops.unique=true
pd 20

Testing

int main() {
    int a = 0xDEADBEEF;
    int b = 0xDEADBEEF;  // Same as a
    int c = 0xDEADBEEF;  // Same as a
    int d = 0xCAFEBABE;  // Different
    int e = 0xDEADBEEF;  // Same as a
    return a + b + c + d + e;
}

gcc -o /tmp/test_colors /tmp/test_colors.c

Test 1: Without Unique Colors (Default Behavior)

r2 -qc 'e scr.color=3; e scr.color.ops=true; e scr.color.ops.unique=false; s main; pd 15' /tmp/test_colors

Expected: All immediate values (0xdeadbeef and 0xcafebabe) appear in the SAME default color.

Test 2: With Unique Colors (New Feature)

r2 -qc 'e scr.color=3; e scr.color.ops=true; e scr.color.ops.unique=true; s main; pd 15' /tmp/test_colors

Expected:

All four 0xDEADBEEF values appear in the SAME color (e.g., blue)
0xCAFEBABE appears in a DIFFERENT color (e.g., magenta)

Test 3: Similar Hex Values (Main Use Case)

int main() {
    long long a = 0x1234567890ABCDEF;
    long long b = 0x1234567890ABCDEE;  // Differs by last digit only
    return 0;
}

gcc -o /tmp/test_similar /tmp/test_similar.c

Expected: The two similar hex values will have DIFFERENT colors, making it easy to spot they're different.

[trufae]

i think that's what scr.rainbow does already

[trufae]

can you confirm or improve that option instead of adding more? also i dislike the scr.color.ops.unique

[vicky-dx]

can you confirm or improve that option instead of adding more? also i dislike the scr.color.ops.unique

@trufae I tested scr.rainbow and it's different from this PR:

scr.rainbow:

• Colors based on address ("shows rainbow colors depending of address")
• Each instruction at a different address gets a different color
• Not related to immediate values

This PR (scr.color.ops.unique):

• Colors based on immediate value content
• Same immediate value = same color (e.g., all 0xdeadbeef in blue)
• Different immediate values = different colors (e.g., 0xcafebabe in magenta)
• Helps distinguish similar hex values like 0x1234567890abcdef vs 0x1234567890abcdee

but if you want
i can make it part of existing scr.color.ops
Instead of new boolean, i'll make scr.color.ops an enum:

scr.color.ops=0 → no coloring
scr.color.ops=1 → basic coloring (current)
scr.color.ops=2 → unique immediate coloring (new)

what's your thought on that?

[trufae]

Agree its not exactly the same.

That seems interesting too, because it feels like how scr.color works. But i think .ops is not the best name we can use here. maybe something like scr.color.imm will fit better, also we can have =3 to colorize using the same addr-to-color code from the rainbow and maybe we can do the same for asm.addr and remove the scr.rainbow? buit that will be another pr! lets finish some of yours first before opening more fronts!

[vicky-dx]

Agree its not exactly the same.

That seems interesting too, because it feels like how scr.color works. But i think .ops is not the best name we can use here. maybe something like scr.color.imm will fit better, also we can have =3 to colorize using the same addr-to-color code from the rainbow and maybe we can do the same for asm.addr and remove the scr.rainbow? buit that will be another pr! lets finish some of yours first before opening more fronts!

I have few concerns

scr.color.imm = 0   → no immediate coloring (but what about scr.color.ops?)
scr.color.imm = 1   → basic coloring
scr.color.imm = 2   → unique coloring

don't you think it will crate ambiguity?

What if scr.color.ops = true but scr.color.imm = 0?
Does scr.color.imm override scr.color.ops for immediates only?

what i was thinking of doing ->

scr.color.ops = false   → no operand coloring at all
scr.color.ops = true    → basic operand coloring
   ─ scr.color.ops.imm = 0   → basic immediate coloring
   ─ scr.color.ops.imm = 1   → unique immediate coloring

this looks clearer to me, because of hierarchy obvious
no ambiguity if parent is false, children don't matter
consistent with radare2's existing config style,
and src.color.ops remains the mater switch for all operands

or simpler

scr.color.ops.imm = 0   → basic coloring (default)
scr.color.ops.imm = 1   → unique coloring

so whats your thought on this?