Hello Stefan,
On Fri, Mar 05, 2021 at 07:39:04AM +0000, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier stefan.herbrechtsmeier@weidmueller.com
The part number sub-command returns the hexadecimal value with a leading 0x.
That's to make sure that: - users have clear and unequivocal feedback that '10' returned by the command is really HEX 10, not DEC 10. - other U-Boot commands which need to take '0x10' as input will interpret it correctly, regardless of the way these other commands implement ascii-to-integer conversion.
This is inconsistent with other values in the command
It could be, but it is then better to fix the inconsistency in those commands/sub-commands which add the ambiguity.
and U-Boot uses hexadecimal values generally.
The key word is "generally", but not always. Some U-Boot commands will process '10' as HEX 10 and some will process 10 as DEC 10. So, in order to avoid these games, I vote for leaving the 0x in place.
Signed-off-by: Stefan Herbrechtsmeier stefan.herbrechtsmeier@weidmueller.com
cmd/part.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/part.c b/cmd/part.c index 3395c17b89..56e1852c66 100644 --- a/cmd/part.c +++ b/cmd/part.c @@ -152,7 +152,7 @@ static int do_part_info(int argc, char *const argv[], enum cmd_part_info param) snprintf(buf, sizeof(buf), LBAF, info.size); break; case CMD_PART_INFO_NUMBER:
snprintf(buf, sizeof(buf), "0x%x", part);
snprintf(buf, sizeof(buf), "%x", part);