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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.