Add + to positive offsets in a better way

[fuzz6001]

Suppresses excessive "+".
I don't know C#, please modify accordingly.

string[] offsets = new string[] { "-1", "0", "1", "+1", "", "abc", null };

// current
foreach (string o in offsets) {
    string offset = o;
    if (offset?.StartsWith("-") == false)
        offset = $"+{offset}";
    System.Console.Write("[" + offset + "] ");
}
//=> [-1] [+0] [+1] [++1] [+] [+abc] [] 

System.Console.WriteLine();

// this PR
foreach (string o in offsets) {
    string offset = o;
    if (Int32.TryParse(offset, out int i))
        offset = i.ToString("+#;-#;0");
    System.Console.Write("[" + offset + "] ");
}
//=> [-1] [0] [+1] [+1] [] [abc] [] 

[mnadareski]

I'll confirm first if we want 0 to be labeled as +0 first, which I actually think was correct given the use case. As for values that aren't numeric, I don't mind just saying it's the dumping program's fault for putting something in there 😛 I'll keep this open, though, because it's a neat bit of formatting trickery.

[fuzz6001]

My first goal was to fix +0.
Currently redump.org uses 0.
http://redump.org/discs/offset/0

[mnadareski]

I confirmed that 0 should not be positive in Redump with the team, so that part is all good.

I had to look this up because you're pulling out some format characters I'm not used to:

• The inclusion of # means that it will only ever use the first digit in the offset. For example, 1234 and 123 would both result in +1.
• Up to roughly 4 digit values have been observed for offsets, but that's not a guarantee.
• If you can find a way to handle this with the same format specification syntax, then I'll gladly merge it. Otherwise, I may opt for a simpler solution like if the offset is not "0" and it doesn't start with a "-".

[fuzz6001]

In practice, it looks like this.

foreach (int value in new int[] {123, 1234, -123, -1234, 0}) {
    System.Console.Write($"{value.ToString("+#;-#;0")}, ");
}
//=> +123, +1234, -123, -1234, 0, 

Is this the official documentation?
The ";" section separator

[mnadareski]

Yes, that's official. It's odd because in a sibling piece of documentation to that, it indicates that a single # would mean a single digit... Your test shows otherwise, and that's all I honestly needed. Thanks for fixing this.