Hello Stefan,
On Fri, Mar 05, 2021 at 07:39:04AM +0000, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier <[email protected]>
>
> 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 <[email protected]>
>
> ---
>
> 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);
--
Best regards,
Eugeniu Rosca
