Should we replace ABCDh format for hexadecimal numbers to 0xABCD?

[NikolajSchlej]

After a recent discussion with @vit9696 and @Ykidia I've decided to update the output format for hexadecimal numbers from ABCDh to 0xABCD.

Turns out this is a breaking change to almost every tool that uses UEFIExtract's output is some way, so it was quickly reverted.

There could be several arguments for or against such a change, and I'd like to ask y'all on your opinions.

Pro:

• already used since 2013, no need to update anything anywhere
• shorter than the alternative by 1 symbol
• suffixed numbers are easier to compare than prefixed numbers
• looks nicer

Con:

• lots of other tools can't tolerate suffixed numbers when pasting into them
• requires an update of every downstream tool to understand new output format
• can be more familiar to people with programming background

@Ykidia also suggested making this a setting togglable by the user, with the old format being the default, but both me and @vit9696 are against the idea so far.

[platomav]

I'm personally in favor of the "0x" prefix notation and not "h" suffix.

I've always found it difficult to distinguish one small "h" at the end of a number vs the obvious "0x" at the beginning. It's also common to accidentally copy that "h" at the end when doing so manually, which causes others tools to misbehave because they expect hex (0x is easier to cut, IMHO). Also, "0x" is definitely the norm in most codebases/documents (that, at least I, have) seen elsewhere.

Regarding output, the truth is that UEFITool (and its two derivatives) does not have a proper format (yet, I hope) either way. There is no programmatically-parsable output (e.g. json, xml etc) and the workaround involves dealing with the "report" text files and some (very) manual scripting to count "pipe" characters to distinguish columns and rely on free-form title fields which are not strictly defined. Basically, it looks nice when manually viewing, but it's fairly difficult to work with from the perspective of a 3rd party tool which relies on UEFITool output. Not sure how many 3rd party tools have written code to handle the current "report" text file. My point is, a proper (future) output is going to store these values as integers to begin with, so the "0x" or "h" is only going to matter at the UI.

[Ykidia]

Excuse me. Want to know - what about strings such as "Empty (0xFF)"? These still displayed with "0x". Is this by design?

[NikolajSchlej]

Not really, fixed in 367a8f9.

[hughsie]

I don't really mind; it's a few extra lines in lvfs-website to convert from either version. I use 0x in fwupd, although lots of other firmware tools use the 'h' suffix too. Maybe I'd err on "if it ain't broke then don't fix it"