From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 3/4] cmd: bcb: Use strcmp() instead of strncmp() for string literals
Date: Wed, 24 Jul 2019 16:08:29 -0400 [thread overview]
Message-ID: <20190724200829.GA20116@bill-the-cat> (raw)
In-Reply-To: <20190719212614.25527-4-erosca@de.adit-jv.com>
On Fri, Jul 19, 2019 at 11:26:13PM +0200, Eugeniu Rosca wrote:
> Quote from https://patchwork.ozlabs.org/patch/1104244/#2210814:
>
> ----------8<-----------
> strncmp() is chosen for the sake of paranoid/defensive programming.
> Indeed, strncmp() is not really needed when comparing a variable
> with a string literal. We expect strcmp() to behave safely even if the
> string variable is not NUL-terminated.
>
> In the same scenario, Linux v5.2-rc7 uses both strcmp() and strncmp(),
> but the frequency of strcmp() is higher:
>
> $ git --version
> git version 2.22.0
> $ (Linux 5.2-rc7) git grep -En 'strncmp\([^"]*"[[:alnum:]]+"' | wc -l
> 1066
> $ (Linux 5.2-rc7) git grep -En 'strcmp\([^"]*"[[:alnum:]]+"' | wc -l
> 1968
>
> A quick "strcmp vs strncmp" object size test shows that strcmp()
> generates smaller memory footprint (gcc-8, x86_64):
>
> $ (U-Boot) size cmd/bcb-strncmp.o cmd/bcb-strcmp.o
> text data bss dec hex filename
> 3373 400 2048 5821 16bd cmd/bcb-strncmp.o
> 3314 400 2048 5762 1682 cmd/bcb-strcmp.o
>
> So, overall, I agree to use strcmp() whenever variables are compared
> with string literals.
> ----------8<-----------
>
> Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
> Reported-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190724/5d90bea4/attachment.sig>
next prev parent reply other threads:[~2019-07-24 20:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 21:26 [U-Boot] [PATCH v3 0/4] Fixes and improvements in BCB and Android docs [ver #3] Eugeniu Rosca
2019-07-19 21:26 ` [U-Boot] [PATCH v3 1/4] treewide: Fix stale references of Android docs Eugeniu Rosca
2019-07-24 20:08 ` Tom Rini
2019-07-19 21:26 ` [U-Boot] [PATCH v3 2/4] cmd: bcb: Fix duplicated handling in two case-branches Eugeniu Rosca
2019-07-24 20:08 ` Tom Rini
2019-07-19 21:26 ` [U-Boot] [PATCH v3 3/4] cmd: bcb: Use strcmp() instead of strncmp() for string literals Eugeniu Rosca
2019-07-22 11:58 ` Igor Opaniuk
2019-07-24 20:08 ` Tom Rini [this message]
2019-07-19 21:26 ` [U-Boot] [PATCH v3 4/4] cmd: bcb: Apply non-functional refinements Eugeniu Rosca
2019-07-24 20:08 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190724200829.GA20116@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox