[PATCH] cmd: part: number: remove inconsistent 0x from returned value

[Eugeniu Rosca]

Hello Stefan,

On Fri, Mar 05, 2021 at 07:39:04AM +0000, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier <stefan.herbrechtsmeier at 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 at 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);

-- 
Best regards,
Eugeniu Rosca