From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniu Rosca Date: Fri, 5 Mar 2021 12:52:18 +0100 Subject: [PATCH] cmd: part: number: remove inconsistent 0x from returned value In-Reply-To: <20210305073904.576-1-stefan.herbrechtsmeier-oss@weidmueller.com> References: <20210305073904.576-1-stefan.herbrechtsmeier-oss@weidmueller.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Stefan, On Fri, Mar 05, 2021 at 07:39:04AM +0000, Stefan Herbrechtsmeier wrote: > From: Stefan Herbrechtsmeier > > 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 > > --- > > 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